the same sense as the global certification keys 2811, 2813, and 
2814, or they may be restricted to use within a defined group of 
VDE instances. 

To perform this installation, the installer retrieves the 
destination site's identity certificate(s) 2823, and from that 
extracts the site public key(s) 2815. These key(s) may be used in 
an encryption process 2841 to protect the keys being installed. 
The key(s) being installed are then transmitted inside the 
destination site's PPE 650. Inside the PPE 650, the decryption 
process 2842 may use the site private key(s) 2816 to decrypt the 
transmission. The PPE 650 then stores the installed or updated 
keys in its key storage 2802. 

Object-Specific Key Use 

Figures 66 and 67 illustrate the use of keys in protecting 
data and control information associated with VDE objects 300. 

Figure 66 shows use of a stationary content object 850 
whose control information is derived from an administrative 
object 870. The objects may be received by the PPE 650 (e.g., by 
retrieval from an object repository 728 over a network or 
retrieved from local storage). The administrative object 
decryption process 2843 may use the private header key(s) 2815 
to decrypt the administrative object 870, thus retrieving the 



WU96/Z7id3 

PERC 808 governing access to the content object 850. The 
private body key(s) 810 may then be extracted from the PERC 
808 and used by the content decryption process 2845 to make the 
content available outside the PPE 650. In addition, the database 
key(s) 2817 may be used by the encryption process 2844 to 
prepare the PERC for storage outside the PPE 650 in the secure 
database 610, In subsequent access to the content object 850, the 
PERC 808 may be retrieved from the secure database 610, 
decrypted with database key(s) 2817, and used directly, rather 
than being extracted from administrative object 870. 

Figure 67 shows the similar process involving a traveling 
object 860. The principal distinction between Figures 66 and 67 
is that the PERC 808 is stored directly within the traveling object 
860, and therefore may be used immediately after the decryption 
process 2843 to provide a private header key(s) 2831. This 
private header key 2831is used to process content within the 
traveling object 860. 

Secret-Key Variations 

Figures 64 through 67 illustrate the preferred public-key 
embodiment, but may also be used to help understand the secret- 
key versions. In secret-key embodiments, the certification 
.process and the public key encryptions/decryptions are replaced 
with private-key encryptions, and the public key/private-key 



pairs are replaced with individual secret keys that are shared 
between the PPE 650 instance and the other parties (e.g., the 
load module suppliers), the PPE manufacturer). In addition, the 
certificate generation process 2804 is not performed in secret-key 
embodiments, and no site identity certificates 2823 or VDE 
certificate database 2803 exist. 

Key Types 

The detailed descriptions of key types below further 
explain secret-key embodiments; this summary is not intended as 
a complete description.The preferred embodiment PPE 650 can 
use different types of keys and/or different "shared secrets" for 
different purposes. Some key types apply to a Public-Key/Secret 
Key implementation, other keys apply to a Secret Key only 



implementation, and still other key types apply to both. The 
following table lists examples of various key and "shared secret'' 
information used in the preferred embodiment, and where this 
information is used and stored: 



K*y/S«er*t Information Typo 


Used in PK or Non- 
PE 


SxampU Storage LocationU) 


Master Key(s) (may include 
some of the specific keys 


Both 


PPE 

Manufacturing facility 
VDE administrator 


Manufacturing Key 


Both (PK optional) 


PPE (PKcase) 
Manufacturing facility 


Certification key pair 


PK 


PPE 

Certification repository 


Public/private key pair 


PK 


UUC 1 

rrt 

Certification repository (Public Key 
only) 


Initial secret key 




PPE 


PPE manufacturing ID 


Non-PK 


PPE 


Site ID, shared code, shared 






Download authorization key 


Both 


PPE 

VDE administrator 


External communication keys 
and other info 


Both 


PPE 

Secure Database 


Administrative obiect kevs 


Both 


Permission record 


Stationary obiect kevs 


Both 


Permission record 


Traveling object shared kevs 


Both 


Permission record 


Secure database kevs 


Both 


PPE 


Private body keys 


Both 


Secure database 
Some objects 


Content keys 


Both 


Secure database 
Some objects 


Authorization shared secrets 


Both 


Permission record 


Secure Database Back up 
kevs 


Both 


PPE 

Secure database 



Master Keys 

A "master" key is a key used to encrypt other keys. An 
initial or "master" key may be provided within PPE 650 for 
communicating other keys in a secure way. During initialization 
of PPE 650, code and shared keys are downloaded to the PPE. 
Since the code contains secure convolution algorithms and/or 
coefficients, it is comparable to a "master key." The shared keys 
may also be considered "master keys." 

If public-key cryptography is used as the basis for external 
communication with PPE 650, then a master key is required 
during the PPE Public-key pair certification process. This 
master key may be, for example, a private key used by the 
manufacturer or VDE administrator to establish the digital 
certificate (encrypted public key and other information of the 
PPE), or it may, as another example, be a private key used by a 
VDE administrator to encrypt the entries in a certification 
repository. Once certification has occurred, external 
communications between PPEs 650 may be established using the 
certificates of communicating PPEs. 

If shared secret keys are used as the basis for external 
communications, then an initial secret key is required to 
establish external communications for PPE 650 initialization. 
This initial secret key is a "master key 44 in the sense that it is 
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used to encrypt other keys. A set of shared partial external 
communications keys (see discussion above) may be downloaded 
during the PPE initialization process, and these keys are used to 
establish subsequent external PPE communications. 

Manufacturing Key 

A manufacturing key is used at the time of PPE 
manufacture to prevent knowledge by the manufacturing staff of 
PPE-specific key information that is downloaded into a PPE at 
initialization time. For example, a PPE 650 that operates as part 
of the manufacturing facility may generate information for 
download into the PPE being initialized. This information must 
be encrypted during communication between the PPEs 650 to 
keep it confidential, or otherwise the manufacturing staff could 
read the information. A manufacturing key is used to protect the 
information. The manufacturing key may be used to protect 
various other keys downloaded into the PPE such as, for 
example, a certification private key, a PPE public/private key 
pair, and/or other keys such as shared secret keys specific to the 
PPE. Since the manufacturing key is used to encrypt other keys, 
it is a "master key." 

A manufacturing key may be public-key based, or it may be 
based on a shared secret. Once the information is downloaded, 
the now-initialized PPE 650 can discard (or simply not use) the 



manufacturing key. A manufacturing key may be hardwired into 
PPE 650 at manufacturing time, or sent to the PPE as its first 
key and discarded after it is no longer needed. As indicated in 
the table above and in the preceding discussion, a manufacturing 
key is not required if PK capabilities are included in the PPE. 

Certification Key Pair 

A certification key pair may be used as part of a 
"certification 41 process for PPEs 650 and VDE electronic 
appliances 600. This certification process in the preferred 
embodiment may be used to permit a VDE electronic appliance to 
present one or more "certificates" authenticating that it (or its 
key) can be trusted. As described above, this "certification" 
process may be used by one PPE 650 to "certify" that it is an 
authentic VDE PPE, it has a certain level of security and 
capability set (e.g., it is hardware based rather than merely 
software based), etc. Briefly, the "certification" process may 
involve using a certificate private key of a certification key pair to 
encrypt a message including another VDE node's public-key. The 
private key of a certification key pair is preferably used to 
generate a PPE certificate. It is used to encrypt a public-key of 
the PPE. A PPE certificate can either be stored in the PPE, or it 
may be stored in a certification repository. 
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Depending on the authentication technique chosen, the 
public key and the private key of a certification key pair may 
need to be protected. In the preferred embodiment, the 
certification public key(s) is distributed amongst PPEs such that 
they may make use of them in decrypting certificates as an 
aspect of authentication. Since, in the preferred embodiment, 
this public key is used inside a PPE 650, there is no need for this 
public key to be available in plaintext, and in any event it is 
important that such key be maintained and transmitted with 
integrity (e.g., during initialization and/or update by a VDE 
administrator). If the certification public key is kept confidential 
(i.e., only available in plaintext inside the PPE 650), it may make 
cracking security much more difficult. The private key of a 
certification key pair should be kept confidential and only be 
stored by a certifying authority (i.e., should not be distributed). 

In order to allow, in the preferred embodiment, the ability 
to differentiate installations with different levels/degrees of 
trustedness/security, different certification key pairs may be used 
(e.g., different certification keys may be used to certify SPEs 503 
then are used to certify HPEs 655). 

PPE Public/Private Kay Pair 

In the preferred embodiment, each PPE 650 may have its 
own unique "device" (and/or user) public/private key pair. 



Preferably, the private key of this key pair is generated within 
the PPE and is never exposed in any form outside of the PPE. 
Thus, in one embodiment, the PPE 650 may be provided with an 
internal capability for generating key pairs internally. If the 
PPE generates its own public-key ciypto-system key pairs 
internally, a manufacturing key discussed above may not be 
needed. If desired, however, for cost reasons a key pair may be 
exposed only at the time a PPE 650 is manufactured, and may be 
protected at that time using a manufacturing key. Allowing PPE 
650 to generate its public key pair internally allows the key pan- 
to be concealed, but may in some applications be outweighed by 
the cost of putting a public-key key pair generator into PPE 650. 

Initial Secret Key 

The initial secret key is used as a master key by a secret 
key only based PPE 650 to protect information downloaded into 
the PPE during initialization. It is generated by the PPE 650, 
and is sent from the PPE to a secure manufacturing database 
encrypted using a manufacturing key. The secure database 
sends back a unique PPE manufacturing ID encrypted using the 
initial secret key in response. 

The initial secret key is likely to be a much longer key than 
.keys used for "standard" encryption due to its special role in PPE 
initialization. Since the resulting decryption overhead occurs 
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only during the initialization process, multiple passes through 
the decryption hardware with selected portions of this key are 
tolerable. 

PPE Manufacturing ID 

The PPE manufacturing ID is not a "key," but does fall 
within the classic definition of a "shared secret." It preferably 
uniquely identifies a PPE 650 and may be used by the secure 
database 610 to determine the PPE's initial secret key during the 
PPE initialization process. 

Site ID, Shared Code, Shared Keys and Shared Secrets 

The VDE site ID along with shared code, keys and secrets 
are preferably either downloaded into PPE 650 during the PPE 
initialization process, or are generated internally by a PPE as 
part of that process. In the preferred embodiment, most or all of 
this information is downloaded. 

The PPE site ID uniquely identifies the PPE 650. The site 
ID is preferably unique so as to uniquely identify the PPE 650 
and distinguish that PPE from all other PPEs. The site ID in the 
preferred embodiment provides a unique address that may be 
used for various purposes, such as for example to provide 
"address privacy" functions. In some cases, the site ID may be 
the public key of the PPE 650. In other cases, the PPE site ID 



may be assigned during the manufacturing and/or initialization 
process. In the case of a PPE 650 that is not public-key-capable, 
it would not be desirable to use the device secret key as the 
unique site ID because this would expose too many bits of the 
key — and therefore a different information string should be used 
as the site ID. 



Shared code comprises those code fragments that provide 
at least a portion of the control program for the PPE 650. In the 
preferred embodiment, a basic code fragment is installed during 
PPE manufacturing that permits the PPE to bootstrap and begin 
the initialization process. This fragment can be replaced during 
the initialization process, or during subsequent download 
processing, with updated control logic. 

Shared keys may be downloaded into PPE 650 during the 
initialization process. These keys may be used, for example, to 
decrypt the private headers of many object structures. 

When PPE 650 is operating in a secret key only mode, the 
initialization and download processes may import shared secrets 
into the PPE 650. These shared secrets may be used during 
communications processes to permit PPEs 650 to authenticate 
the identity of other PPEs and/or users. 
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Download Authorization Key 

The download authorization key is received by PPE 650 
during the initialization download process. It is used to authorize 
further PPE 650 code updates, key updates, and may also be 
used to protect PPE secure database 610 backup to allow 
recovery by a VDE administrator (for example) if the PPE fails. 
It may be used along with the site ID, time and convolution 
algorithm to derive a site ID specific key. The download 
authorization key may also be used to encrypt the key block used 
to encrypt secure database 610 backups. It may also be used to 
form a site specific key that is used to enable future downloads to 
the PPE 650. This download authorization key is not shared 
among all PPEs 650 in the preferred embodiment; it is specific to 
functions performed by authorized VDE administrators. 

External Communicationfi Keys and Related Secret and Public 
Information 

There are several cases where keys are required when 
PPEs 650 communicate. The process of establishing secure 
communications may also require the use of related public and 
secret information about the communicating electronic 
appliances 600. The external communication keys and other 
information are used to support and authenticate secure 
communications. These keys comprise a public-key pair in the 



preferred embodiment although shared secret keys may be used 
alternatively or in addition. 

Administrative Object Keys 

In the preferred embodiment, an administrative object 
shared key may be used to decrypt the private header of an 
administrative object 870. In the case of administrative objects, a 
permissions record 808 may be present in the private header. In 
some cases, the permissions record 808 may be distributed as (or 
within) an administrative object that performs the function of 
providing a right to process the content of other administrative 
objects. The permissions record 808 preferably contains the keys 
for the private body, and the keys for the content that can be 
accessed would be budgets referenced in that permissions record 
808. The administrative object shared keys may incorporate time 
as a component, and may be replaced when expired. 

Stationary Object Keys 

A stationary object shared key may be used to decrypt a 
private header of stationary objects 850. As explained above, in 
some cases a permissions record 808 may be present in the 
private header of stationary objects. If present, the permissions 
record 808 may contain the keys for the private body but will not 
contain the keys for the content. These shared keys may 



incorporate time as a component, and may be replaced when 
expired. 

Traveling Object Shared Keys 

A traveling object shared key may be used to decrypt the 
private header of traveling objects 860. In the preferred 
embodiment, traveling objects contain permissions record 808 in 
their private headers. The permissions record 808 preferably 
contains the keys for the private body and the keys for the 
content that can be accessed as permitted by the permissions 
record 808. These shared keys may incorporate time as a 
component, and may be replaced when expired. 

Secure Database Kbjtb 

PPE 650 preferably generates these secure database keys 
and never exposes them outside of the PPE. They are site- 
specific in the preferred embodiment, and may be "aged" as 
described above. As described above, each time an updated 
record is written to secure database 610, a new key may be used 
and kept in a key list within the PPE. Periodically (and when the 
internal list has no more room), the PPE 650 may generate a new 
key to encrypt new or old records. A group of keys may be used 
instead of a single key, depending on the size of the secure 
database 610. 
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Private Body Keys 

Private body keys are unique to an object 300, and are not 
dependent on key information shared between PPEs 650. They 
are preferably generated by the PPE 650 at the time the private 
body is enciypted, and may incorporate real-time as a component 
to "age* them. They are received in permissions records 808, and 
their usage may be controlled by budgets. 

Content Keys 

Content Keys are unique to an object 300, and are not 
dependent on key information shared between PPEs 650. They 
are preferably generated by the PPE 650 at the time the content 
is encrypted. They may incorporate time as a component to "age" 
them. They are received in permissions records 808, and their 
usage may be controlled by budgets. 

Authorization Shared Secrets 

Access to and use of information within a PPE 650 or 
within a secure database 610 may be controlled losing 
authorization "shared secrets" rather than keys. Authorization 
shared secrets may be stored within the records they authorize 
ipermissions records 808, budget records, etc.). The 
authorization shared secret may be formulated when the 
corresponding record is created. Authorization shared secrets 
can be generated by an authorizing PPE 650, and may be 



replaced when record updates occur. Authorization shared 
secrets have some characteristics associated with "capabilities" 
vised in capabilities based operating systems. Access tags 
(described below) are an important set of authorization shared 
secrets in the preferred embodiment. 

Backup Keys 

As described above, the secure database 610 backup 
consists of reading all secure database records and current audit 
"roll ups" stored in both PPE 650 and externally. Then, the 
backup process decrypts and re-encrypts this information using a 
new set of generated keys. These keys, the time of the backup, 
and other appropriate information to identify the backup, may be 
encrypted multiple times and stored with the previously 
encrypted secure database files and roll up data within the 
backup files. These files may then all be encrypted using a 
"backup key" that is generated and stored within PPE 650. This 
backup key 500 may be used by the PPE to recover a backup if 
necessary. The backup keys may also be securely encrypted (e.g., 
using a download authentication key and/or a VDE administrator 
public key) and stored within the backup itself to permit a VDE 
administrator to recover the backup in case of PPE 650 failure. 
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Cryptographic Sealing 

Sealing is used to protect the integrity of information when 
it may be subjected to modifications outside the control of the 
PPE 650, either accidentally or as an attack on the VDE security. 
Two specific applications may be the computation of check values 
for database records and the protection of data blocks that are 
swapped out of an SPE 500. 

There are two types of sealing: keyless sealing, also known 
as cryptographic hashing, and keyed sealing. Both employ a 
cryptographically strong hash function, such as MD5 or SHA. 
Such a function takes an input of arbitrary size and yields a 
fixed-size hash, or "digest* The digest has the property that it is 
infeasible to compute two inputs that yield the same digest, and 
infeasible to compute one input that yields a specific digest value, 
where "infeasible" is with reference to a work factor based on the 
size of the digest value in bits. If, for example, a 256-bit hash 
function is to be called strong, it must require approximately on 
average 10 A 38 (2 A 128) trials before a duplicated or specified 
digest value is likely to be produced. 

Keyless seals may be employed as check values in database 
records (e.g., in PERC 808) and similar applications. A keyless 
seal inay be computed based on the content of the body Qf the 
record, and the seal stored with the rest of the record. The 
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combination of seal and record may be encrypted to protect it in 
storage. If someone modifies the encrypted record without 
knowing the encryption key (either in the part representing the 
data or the part representing the seal), the decrypted content will 
be different, and the decrypted check value will not match the 
digest computed from the record's data. Even though the hash 
algorithm is known, it is not feasible to modify both the record's 
data and its seal to correspond because both are encrypted. 

Keyed seals may be employed as protection for data stored 
outside a protected environment without encryption, or as a 
validity proof between two protected environments. A keyed seal 
is computed similarly to a keyless seal, except that a secret initial 
value is logically prefixed to the data being sealed. The digest 
value thus depends both on the secret and the data, and it is 
infeasible to compute a new seal to correspond to modified data 
even though the data itself is visible to an attacker. A keyed seal 
may protect data in storage with a single secret value, or may 
protect data in transit between two environments that share a 
single secret value. 

The choice of keys or keyless seals depends on the nature 
of the data being protected and whether it is additionally 
protected by encryption. 
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Tagging 

Tagging is particularly useful for supporting the secure 
storage of important component assembly and related 
information on secondary storage memory 652. Integrated use of 
information "tagging" and encryption strategies allows use of 
inexpensive mass storage devices to securely store information 
that, in part enables, limits and/or records the configuration, 
management and operation of a VDE node and the use of VDE 
protected content. 

When encrypted or otherwise secured information is 
delivered into a user's secure VDE processing area (e.g., PPE 
650), a portion of this information can be used as a "tag" that is 
first decrypted or otherwise unsecured and then compared to an 
expected value to confirm that the information represents 
expected information. The tag thus can be used as a portion of a 
process confirming the identity and correctness of received, VDE 
protected, information. 

Three classes of tags that may be included in the control 
structures of the preferred embodiment: 

• access tags 

• validation tags 

• correlation tags. 
These tags have distinct purposes. 



An access tap may be used as a "shared secret" between 
VDE protected elements and entities authorized to read and/or 
modify the tagged elements). The access tag may be broken into 
separate fields to control different activities independently. If an 
access tag is used by an element such as a method core 1000', 
administrative events that affect such an element must include 
the access tag (or portion of the access tag) for the affected 
element(s) and assert that tag when an event is submitted for 
processing. If access tags are maintained securely (e.g., created 
inside a PPE 650 when the elements are created, and only 
released from PPE 650 in encrypted structures), and only 
distributed to authorized parties, modification of structures can 
be controlled more securely. Of course, control structures (e.g., 
PERCs 808) may further limit or qualify modifications or other 
actions expressed in administrative events. 

Correlation taps are used when one element references 
another element. For example, a creator might be required by a 
budget owner to obtain permission and establish a business 
relationship prior to referencing their budget within the creator's 
PERCs. After such relationship was formed, the budget owner 
might transmit one or more correlation tags to the creator as one 
aspect of allowing the creator to produce PERCs that reference 
the budget owner's budget. 
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Ynli flatinn tags may be used to help detect record 
substitution attempts on the part of a tamperer. 

In some respects, these three classes of tags overlap in 
function. For example, a correlation tag mismatch may prevent 
some classes of modification attempts that would normally be 
prevented by an access tag mismatch before an access tag check 
is performed. The preferred embodiment may use this overlap in 
some cases to reduce overhead by, for example, using access tags 
in a role similar to validation tags as described above. 

In general, tagging procedures involve changing, within 
SPE 503, encryption key(s), securing techniques(s), and/or 
providing specific, stored tag(s). These procedures can be 
employed with secure database 610 information stored on said 
inexpensive mass storage 652 and used within a hardware SPU 
500 for authenticating, decrypting, or otherwise analyzing, using 
and making available VDE protected content and management 
database information- Normally, changing validation tags 
involves storing within a VDE node hardware (e.g., the PPE 650) 
one or more elements of information corresponding to the tagging 
changes. Storage of information outside of the hardware SPE's 
physically secure, trusted environment is a highly cost savings 
means of secure storage, and the security of important stored 
management database information is enhanced by this tagging of 



information. Performing this tagging "change* frequently (for 
example, every time a given record is decrypted) prevents the 
substitution of "incorrect" information for "correct" information, 
since said substitution will not carry information which will 
match the tagging information stored within the hardware SPE 
during subsequent retrieval of the information. 

Another benefit of information tagging is the use of tags to 
help enforce and/or verify information and/or control mechanisms 
in force between two or more parties. If information is tagged by 
one party, and then passed to another party or parties, a tag can 
be used as an expected value associated with communications 
and/or transactions between the two parties regarding the tagged 
information. For example, if a tag is associated with a data 
element that is passed by Party A to Party B, Party B may 
require Party A to prove knowledge of the correct value of at least 
a portion of a tag before information related to, and/or part of, 
said data element is released by Party B to Party A, or vice versa. 
In another example, a tag may be used by Party A to verify that 
information sent by Party B is actually associated with, and/or 
part of, a tagged data element, or vice versa. 

Establishing A Secure, Authenticated, Communication Channel 

From time to time, two parties (e.g., PPEs A and B), will 
need to establish a communication channel that is known by both 



parties to be secure from eavesdropping, secure from tampering, 
and to be in use solely by the two parties whose identifies are 
correctly known to each other. 

The following describes an example process for establishing 
such a channel and identifies how the requirements for security 
and authentication may be established and validated by the 
parties. The process is described in the abstract, in terms of the 
claims and belief each party must establish, and is not to be 
taken as a specification of any particular protocol. In particular, 
the individual sub-steps of each step are not required to be 
implemented using distinct operations; in practice, the 
establishment and validation of related proofs is often combined 
into a single operation. 

The sub-steps need not be performed in the order detailed 
below, except to the extent that the validity of a claim cannot be 
proven before the claim is made by the other party. The steps 
may involve additional communications between the two parties 
than are implied by the enumerated sub-steps, as the 
"transmission" of information may itself be broken into sub-steps. 
Also, it is not necessary to protect the claims or the proofs from 
disclosure or modification during transmission. Knowledge of the 
claims (including the specific communication proposals and 
acknowledgements thereof) is not considered protected 
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information. Any modification of the proofs will cause the proofs 
to become invalid and will cause the process to fail. 

Standard public-key or secret-key cryptographic 
techniques can be used to implement this process (e.g., X.509, 
Authenticated Diffie-Hellman, Kerberos). The preferred 
embodiment uses the three-way X.509 public key protocol steps. 

The following may be the first two steps in the example 
process: 

A. {precursor step): Establish means of creating 

validatable claims by A 

B. (precursor step): Establish means of creating 

validatable claims by B 

These two steps ensure that each party has a means of 
making claims that can be validated by the other party, for 
instance, by using a public key signature scheme in which both 
parties maintain a private key and make available a public key 
that itself is authenticated by the digital signature of a 
certification authority. 

The next steps may be: 

A fprnpftft* 1 step): 

1. Determine B's identity 
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Acquire means of validating claims made by B 
Create a unique identity for this specific proposed 
communication 

Create a communication proposal identifying the 
parties and the specific communication 
Create validatable proof of A's identity and the 
origin of the communication proposal 
Deliver communication proposal and associated 
proof to B. 



These steps establish the identity of the correspondent 
party B and proposes a communication. Because establishment 
of the communication will require validation of claims made by B, 
a means must be provided for A to validate such claims. Because 
the establishment of the communication must be unique to a 
specific requirement by A for communication, this communication 
proposal and all associated traffic must be unambiguously 
distinguishable from all other such traffic. Because B must 
validate the proposal as a legitimate proposal from A, a proof 
must be provided that the proposal is valid. 



The next steps may be as follows: 
R r Acknowledgement step): 

1 . Extract A's identity firom the communication 
proposal 

2. Acquire means of validating claims made by A 

3. Validate A's claim of identity and communication 
proposal origin 

4 . Determine the unique identification of the 
communication proposal 

5. Determine that the communication proposal does not 
duplicate an earlier proposal 

6. Create an acknowledgement identifying the specific 
communication proposal 

7. Create validatable proof of B's identity and the 
origin of the acknowledgement 

8. Deliver the acknowledgement and associated proof to 
A. 



These steps establish that party B has received A's 
communication proposal and is prepared to act on it. Because B 
must validate the proposal, B must first determine its origin and 
validate its authenticity. B must ensure that its response is 
associated with a specific proposal, and that the proposal is not a 
replay. If B accepts the proposal, it must prove both B's own 
identity and that B has received a specific proposal. 



The next steps may be: 
A (A«tflMiflhmentstep): 

1 . Validate B's claim acknowledgement of A's specific 
proposal 

2. Extract the identity of the specific communication 
proposal from the acknowledgement 

3. Determine that the acknowledgement is associated 
with an outstanding communication proposal 

4. Create unique session key to be used for the 
proposed communication 

5. Create proof of session key's creation by A 

6. Create proof of session key's association with the 
specific communication proposal 

7 . Create proof of receipt of B's acknowledgement 

8. Protect the session key from disclosure in 
transmission 

9. Protect the session key from modification in 
transmission 

10. Deliver protected session key and all proofs to B. 

These steps allows A to specify a session key to be 
associated with all further traffic related to As specific 
communication proposal. A must create the key, prove that A 
.created it, and prove that it is associated with the specific 
proposed communication. In addition, A must prove that the 



session key is generated in response to B's acknowledgement of 
the proposal. The session key must be protected from disclosure 
of modification to ensure that an attacker cannot substitute a 
different value* 

Transportability ofVDE Installations Between FPEs 660 

In a preferred embodiment, VDE objects 300 and other 
secure information may if appropriate, be transported from one 
PPE 650 to another securely using the various keys outlined 
above. VDE 100 uses redistribution of VDE administrative 
information to exchange ownership of VDE object 300, and to 
allow the portability of objects between electronic appliances 600. 

The permissions record 808 of VDE objects 300 contains 
rights information that may be used to determine whether an 
object can be redistributed in whole, in part, or at all. If a VDE 
object 300 can be redistributed, then electronic appliance 600 
normally must have a "budget" and/or other permissioning that 
allows it to redistribute the object. For example, an electronic 
appliance 600 authorized to redistribute an object may create an 
administrative object containing a budget or rights less than or 
equal to the budget or rights that it owns. Some administrative 
objects may be sent to other PPEs 650. A PPE 650 that receives 
one of the administrative objects may have the ability to use at 
least a portion of the budgets, or rights, to related objects. 



Transfer of ownership of a VDE object 300 is a special case 
in which all of the permissions and/or budgets for a VDE object 
are redistributed to a different PPE 650. Some VDE objects may 
require that all object-related information be delivered (e.g., it's 
possible to n selT all rights to the object). However, some VDE 
objects 300 may prohibit such a transfer. In the case of 
ownership transfer, the original providers for a VDE object 300 
may need to be contacted by the new owner, informed of the 
transfer, and validated using an authorization shared secret that 
accompanies reauthorization, before transfer of ownership can be 
completed. 

When an electronic appliance 600 receives a component 
assembly, an encrypted part of the assembly may contain a value 
that is known only to the party or PPE 650 that supplied the 
assembly. This value may be saved with information that must 
eventually returned to the assembly supplier (e.g., audit, billing 
and related information). When a component supplier requests 
that information be reported, the value may be provided by the 
supplier so that the local electronic appliance 600 can check it 
against the originally supplied value to ensure that the request is 
legitimate. When a new component is received, the value may be 
checked against an old component to determine whether the new 
component is legitimate (e.g., the new value for use in the next 
report process may be included with the new component). 



Integrity of VDE Security 

There are many ways in which a PPE 650 might be 
compromised. The goal of the security provided by VDE 100 is to 
reduce the possibility that the system will be compromised, and 
minimize the adverse effects if it is compromised. 

The basic cryptographic algorithm that are used to 
implement VDE 100 are assumed to be safe (cryptographically 
strong). These include the secret-key encryption of content, 
public-key signatures for integrity verification, public-key 
encryption for privacy between PPEs 650 or between a PPE and 
a VDE administrator, etc. Direct attack on these algorithms is 
assumed to be beyond the capabilities of an attacker. For 
domestic versions of VDE 100 some of this is probably a safe 
assumption since the basic building blocks for control information 
have sufficiently long keys and are sufficiently proven. 

The following risks of threat or attacks may be significant: 

• Unauthorized creation or modification of component 
assemblies (e.g., budgets) 

• Unauthorized bulk disclosure of content 

• Compromise of one or more keys 

• Software emulation of a hardware PPE 

• Substitution of older records in place of newer 
records 
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Introduction of "rogue* (i.e., unauthentic) load 
modules 
Replay attacks 
Defeating "fingerprinting" 

Unauthorized disclosure of individual content items 
Redistribution of individual content items. 



A significant potential security breach would occur if one or 
more encryption keys are compromised. As discussed above, 
however, the encryption keys used by VDE 100 are sufficiently 
varied and compartmentalized so that compromising one key 
would have only limited value to an attacker in most cases. For 
example, if a certification private key is exposed, an attacker 
could pass the challenge/response protocol as discussed above but 
would then confront the next level of security that would entail 
cracking either the initialization challenge/response or the 
external communication keys. If the initialization 
challenge/response security is also defeated, the initialization 
code and various initialization keys would also be exposed. 
However, it would still be necessary to understand the code and 
data to find the shared VDE keys and to duplicate the key- 
generation ("convolution") algorithms. In addition, correct real 
time clock values must be maintained by the spoof. If the 
attacker is able to accomplish all of this successfully, then all 
secure communications to the bogus PPE would be compromised. 



An object would be compromised if communications related to the 
permissions record 808 of that object are sent to the bogus PPE. 

Knowledge of the PPE download authorization key and the 
algorithms that are used to derive the key that encrypts the keys 
for backup of secured database 610 would compromise the entire 
secured database at a specific electronic appliance 600. However, 
in order to use this information to compromise content of VDE 
objects 300, an understanding of appropriate VDE internals 
would also be required. In a preferred embodiment, the private 
body keys and content keys stored in a secured database 610 are 
"aged" by including a time component. Time is convoluted with 
the stored values to derive the "true keys" needed to decrypt 
content. If this process is also compromised, then object content 
or methods would be revealed. Since a backup of secured 
database 610 is not ever restored to a PPE 650 in the preferred 
embodiment without the intervention of an authorized VDE 
administrator, a "bogus" PPE would have to be used to make use 
of this information. 

External communication shared keys are used in the 
preferred embodiment in conjunction with a key convolution 
algorithm based on site ID and time. If compromised, all of the 
steps necessary to allow communications with PPEs 650 must 
also be known to take advantage of this knowledge. In addition, 



at least one of the administrative object shared keys must be 
compromised to gain access to a decrypted permissions record 
808. 

Compromising an administrative object shared key has no 
value unless the "cracker" also has knowledge of external 
communication keys. All administrative objects are encrypted by 
unique keys exchanged using the shared external 
communications keys, site ID and time. Knowledge of PPE 650 
internal details would be necessary to further decrypt the content 
of administrative objects. 

The private header of a stationary object (or any other 
stationary object that uses the same shared key) if compromised, 
may provide the attacker with access to content until the shared 
key "ages" enough to no longer decrypt the private header. 
Neither the private body nor the content of the object is exposed 
unless a permissions record 808 for that object is also 
compromised. The private headers of these objects may remain 
compromised until the key "ages" enough to no longer decrypt the 
private header. 

Secure database encryption keys in the preferred 
embodiment are frequently changing and are also site specific. 
The consequences of compromising a secured database 610 file or 



WUWZ7133 



a record depends on the information that has been compromised. 
For example, permissions record 808 contain keys for the public 
body and content of a VDE object 300. If a permissions record 
808 is compromised, the aspects of that object protected by the 
keys provided by the permissions record are also 
compromised— if the algorithm that generates the "true keys" is 
also known. If a private body key becomes known, the private 
body of the object is compromised until the key "ages" and 
expires. If the "aging" process for that key is also compromised, 
the breach is permanent. Since the private body may contain 
methods that are shared by a number of different objects, these 
methods may also become compromised. When the breach is 
detected, all administrative objects that provide budgets and 
permissions record should update the compromised methods. 
Methods stored in secure database 610 are only replaced by more 
recent versions, so the compromised version becomes unusable 
after the update is completed. 

If a content key becomes compromised, the portion of the 
content encrypted with the key is also compromised until the key 
"ages" and expires. If the "aging" process for that key also 
becomes compromised, then the breach becomes permanent. If 
multiple levels of encryption are used, or portions of the content 
are encrypted with different keys, learning a single key would be 
insufficient to release some or all of the content. 



If an authorization shared secret (e.g., an access tag) 
becomes known, the record containing the secret may be modified 
by an authorized means if the "cracker" knows how to properly 
use the secret. Generally speaking, the external communications 
keys, the administrative object keys and the management file 
keys must also be "cracked" before a shared secret is useful. Of 
course, any detailed knowledge of the protocols would also be 
required to make use of this information. 

In the preferred embodiment, PPE 650 may detect whether 
or not it has become compromised. For example, by comparing 
information stored in an SPE 503 (e.g., summary service 
information) with information stored in secure database 610 
and/or transmitted to a VDE participant (e.g., a VDE 
clearinghouse), discrepancies may become evident. If PPE 650 
(or a VDE administrator watching its activities or communicating 
with it) detects that it has been compromised, it may be updated 
with an initialization to use new code, keys and new 
encryption/decryption algorithms. This would limit exposure to 
VDE objects 300 that existed at the time the encryption scheme 
was broken. It is possible to require the PPE 650 to cease 
functioning after a certain period of time unless new code and 
key downloads occur. It is also possible to have VDE 
administrators force updates to occur. It is also likely that the 
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desire to acquire a new VDE object 300 will provide an incentive 
for users to update their PPEs 650 at regular time intervals. 

Finally, the end-to-end nature of VDE applications, in 
which content 108 flows in one direction, generating reports and 
bills 118 in the other, makes it possible to perform "back-end" 
consistency checks. Such checks, performed in clearinghouses 
116, can detect patterns of use that may or do indicate fraud (e.g., 
excessive acquisition of protected content without any 
corresponding payment, usage records without corresponding 
billing records). The fine grain of usage reporting and the ready 
availability of usage records and reports in electronic form 
enables sophisticated fraud detection mechanisms to be built so 
that fraud-related costs can be kept to an acceptable level. 

PPE Initialization 

Each PPE 650 needs to be initialized before it can be used. 
Initialization may occur at the manufacturer site, after the PPE 
650 has been placed out in the field, or both. The manufacturing 
process for PPE 650 typically involves embedding within the PPE 
sufficient software that will allow the device to be more 
completely initialized at a later time. This manufacturing 
process may include, for example, testing the bootstrap loader 
and challenge-response software permanently stored within PPE 
650, and loading the PPE's unique ID. These steps provide a 
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basic VDE-capable PPE 650 that may be further initialized (e.g., 
after it has been installed within an electronic appliance 600 and 
placed in the field). In some cases, the manufacturing and 
further initialization processes may be combined to produce 
"VDE ready" PPEs 650. This description elaborates on the 
summary presented above with respect to Figures 64 and 65. 

Figure 68 shows an example of steps that may be 
performed in accordance with one preferred embodiment to 
initialize a PPE 650. Some of the steps shown in this flowchart 
may be performed at the manufacturing site, and some may be 
performed remotely through contact between a VDE 
administrator and the PPE 650. Alternatively, all of the steps 
shown in the diagram may be performed at the manufacturing 
site, or all of the steps shown may be performed through remote 
communications between the PPE 500 and a VDE administrator. 

If the initialization process 1370 is being performed at the 
manufacturer, PPE 650 may first be attached to a testbed. The 
manufacturing testbed may first reset the PPE 650 (e.g., with a 
power on clear) (Block 1372). If this reset is being performed at 
the manufacturer, then the PPE 650 preferably executes a 
special testbed bootstrap code that completely tests the PPE 
• operation from a software standpoint and fails if something is 
wrong with the PPE. A secure communications exchange may 
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then be established between the manufacturing teatbed and the 
PPE 650 using an initial challenge-response interaction (Block 
1374) that is preferably provided as part of the testbed bootstrap 
process. Once this secure communications has been established, 
the PPE 650 may report the results of the bootstrap tests it has 
performed to the manufacturing testbed. Assuming the PPE 650 
has tested successfully, the manufacturing testbed may download 
new code into the PPE 650 to update its internal bootstrap code 
(Block 1376) so that it does not go through the testbed bootstrap 
process upon subsequent resets (Block 1376). The manufacturing 
testbed may then load new firmware into the PPE internal non- 
volatile memory in order to provide additional standard and/or 
customized capabilities (Block 1378). For example, the 
manufacturing testbed may preload PPE 650 with the load 
modules appropriate for the particular manufacturing lot. This 
step permits the PPE 500 to be customized at the factory for 
specific applications. 

The manufacturing testbed may next load a unique device 
ED into PPE 650 (Block 1380). PPE 650 now carries a unique ID 
that can be used for further interactions. 

Blocks 1372-1380R typically are, in the preferred 
embodiment, performed at the manufacturing site. Blocks 1374 



and 1382-1388 may be performed either at the manufacturing 
site, after the PPE 650 has been deployed, or both. 

To further initialize PPE 650, once a secure 
communications has been established between the PPE and the 
manufacturing testbed or a VDE administrator (Block 1374), any 
required keys, tags or certificates are loaded into PPE 650 (Block 
1382). For example, the manufacturing test bed may load its 
information into PPE 650 so the PPE may be initialized at a later 
time. Some of these values may be generated internally within 
PPE 650. The manufacturing testbed or VDE administrator may 
then initialize the PPE real time clock 528 to the current real 
time value (Block 1384). This provides a time and date reference 
for the PPE 650. The manufacturing testbed or the VDE 
administrator may next initialize the summary values 
maintained internally to the PPE 500 (Block 1386). If the PPE 
650 is already installed as part of an electronic appliance 600, the 
PPE may at this point initialize its secure database 610 (Block 
1388). 

Figure 69 shows an example of program control steps 
performed by PPE 650 as part of a firmware download process 
(See Figure 68, Block 1378). The PPE download process is used 
to load externally provided firmware and/or data elements into 
the PPE. Firmware loads may take two forms: permanent loads 
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for software that remains resident in the PPE 650; and transient 
loads for software that is being loaded for execution. A related 
process for storing into the secure database 610 is performed for 
elements that have been sent to a VDE electronic appliance 600. 

PPE 650 automatically performs several checks to ensure 
that firmware being downloaded into the PPE has not been 
tampered with, replaced, or substituted before it was loaded. The 
download routine 1390 shown in the figure illustrates an 
example of such checks. Once the PPE 650 has received a new 
firmware item (Block 1392), it may check the item to ensure that 
it decrypts properly using the predetermined download or 
administrative object key (depending on the source of the 
element) (decision Block 1394). If the firmware decrypts properly 
("yes" exits to decision Block 1394), the firmware as check valve 
may be calculated and compared against the check valve stored 
under the encryption wrapper of the firmware (decision Block 
1396). If the two check summed values compare favorably ("yes" 
exit to decision Block 1396), then the PPE 650 may compare the 
public and private header identification tags associated with the 
firmware to ensure that the proper firmware was provided and 
had not been substituted (step not shown in the figure). 
Assuming this test also passes, the PPE 500 may calculate the 
digital signatures of the firmware (assuming digital signatures 
are supported by the PPE 650 and the firmware is "signed") and 



may check the calculated signature to ensure that it compares 
favorably to the digital signatures under the firmware encryption 
wrapper (Blocks 1398, 1400), If any of these tests fail, then the 
download will be aborted ("fail* termination 1401). 

Assuming all of the tests described above pass, then PPE 
650 determines whether the firmware is to be stored within the 
PPE (e.g., an internal non-volatile memory), or whether it is to be 
stored in the secure database 610 (decision Block 1402). If the 
firmware is to be stored within the PPE Cyes" exit to decision 
Block 1402), then the PPE 500 may simply store the information 
internally (Block 1404). If the firmware is to be stored within the 
secure database 610 Cno a exit to decision Block 1402), then the 
firmware may be tagged with a unique PPE-specific tag designed 
to prevent record substitution (Block 1406), and the firmware 
may then be encrypted using the appropriate secure database 
key and released to the secure database 610 (Block 1408). 

Networking SPUb 500 and/or VDE Electronic Appliances 600 

In the context of many computers interconnected by a local 
or wide area network, it would be possible for one or a few of 
them to be VDE electronic appliances 600. For example, a VDE- 
capable server might include one or more SPUs 500. This 
centralized VDE server could provide all VDE services required 
within the network or it can share VDE service with VDE server 
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nodes; that is, it can perform a few, some, or most VDE service 
activities. For example, a use fa non-VDE computer could issue a 
request over the network for VDE-protected content. In response 
to the request, the VDE server could comply by accessing the 
appropriate VDE object 300, releasing the requested content and 
delive rin g the content over the network 672 to the requesting 
user. Such an arrangement would allow VDE capabilities to be 
easily integrated into existing networks without requiring 
modification or replacement of the various computers and other 
devices connected to the networks. 

For example, a VDE server having one or more protected 
processing environments 650 could communicate over a network 
with workstations that do not have a protected processing 
environment. The VDE server could perform all secure VDE 
processing, and release resulting content and other information 
to the workstations on the network. This arrangement would 
require no hardware or software modification to the 
workstations. 

However, some applications may require greater security, 
flexibility and/or performance that may be obtained by providing 
multiple VDE electronic appliances 600 connected to the same 
. network 672. Because commonly-used local area networks 
constitute an insecure channel that may be subject to tampering 





and/or eavesdropping, it is desirable in most secure applications 
to protect the information communicated across the network. It 
would be possible to use conventional network security 
techniques to protect VDE-released content or other VDE 
information communicated across a network 672 between a VDE 
electronic appliance 600 and a non-VDE electronic appliance. 
However, advantages are obtained by providing multiple 
networked VDE electronic appliances 600 within the same 
system. 

As discussed above in connection with Figure 8, multiple 
VDE electronic appliances 600 may communicate with one 
another over a network 672 or other communications path. Such 
networking of VDE electronic appliances 600 can provide 
advantages. Advantages include, for example, the possibility of 
centralizing VDE resources, storing and/or archiving metering 
information on a server VDE and delivering information and 
services efficiently across the network 672 to multiple electronic 
appliances 600. 

For example, in a local area network topology, a "VDE 
server" electronic appliance 600 could store VDE-protected 
information and make it available to one or more additional 
electronic appliances 600 or computers that may communicate 
with the server over network 672. As one example, an object 



repository 728 storing VDE objects could be maintained at the 
centralized server, and each of many networked electronic 
appliance 600 users could access the centralized object repository 
over the network 672 as needed. When a user needs to access a 
particular VDE object 300, her electronic appliance 600 could 
issue a request over network 672 to obtain a copy of the object. 
The "VDE server" could deliver all or a portion of the requested 
object 300 in response to the request. Providing such a 
centralized object repository 728 would have the advantage of 
TttiTUTttiging mass storage requirements local to each electronic 
appliance 600 connected to the network 672, eliminate redundant 
copies of the same information, ease information management 
burdens, provide additional physical and/or other security for 
particularly important VDE processes and/or information 
occurring at the server, where providing such security at VDE 
nodes may be commercially impractical for certain business 
models, etc. 

It may also be desirable to centralize secure database 610 
in a local area network topology. For example, in the context of a 
local area network, a secure database 610 server could be 
provided at a centralized location. Each of several electronic 
appliances 600 connected to a local area network 672 could issue 
requests for secure database 610 records over the network, and 
receive those records via the network. The records could be 
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provided over the network in encrypted form. "Keys* 1 needed to 
decrypt the records could be shared by transmitting them across 
the network in secure communication exchanges. Centralizing 
secure database 610 in a network 672 has potential advantages 
of TninimiyiTig 0 r eliminating secondary storage and/or other 
memory requirements for each of the networked electronic 
appliances 600, avoiding redundant information storage, allowing 
centralized backup services to be provided, easing information 
management burdens, etc. 

One way to inexpensively and conveniently deploy multiple 
instances of VDE electronic appliances 600 across a network 
would be to provide network workstations with software defining 
an HPE 655. This arrangement requires no hardware 
modification of the workstations; an HPE 655 can be defined 
using software only. An SPE(s) 503 and/or HPE(s) 655 could also 
be provided within a VDE server. This arrangement has the 
advantage of allowing distributed VDE network processing 
without requiring workstations to be customized or modified 
(except for loading a new program(s) into them). VDE functions 
requiring high levels of security may be restricted to an SPU- 
based VDE server. "Secure" HPE-based workstations could 
perform VDE functions requiring less security, and could also 
coordinate their activities with the VDE server. 
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Thus, it may be advantageous to provide multiple VDE 
electronic appliances 600 within the same network. It may also 
be advantageous to provide multiple VDE electronic appliances 
600 within the same workstation or other electronic appliance 
600. For example, an electronic appliance 600 may include 
multiple electronic appliances 600 each of which have a SPU 500 
and are capable of performing VDE functions. 

For example, one or more VDE electronic appliances 600 
can be used as input/output device(s) of a computer system. This 
may eliminate the need to decrypt information in one device and 
then move it in unencrypted form across some bus or other 
unsecured channel to another device such as a peripheral. If the 
peripheral device itself is a VDE electronic appliance 600 having 
a SPU 500, VDE-protected information may be securely sent to 
the peripheral across the insecure channel for processing (e.g., 
decryption) at the peripheral device. Giving the peripheral 
device the capability of handling VDE-protected information 
directly also increases flexibility. For example, the VDE 
electronic appliance 600 peripheral device may control VDE 
object 300 usage. It may, for example, meter the usage or other 
parameters associated with the information it processes, and it 
may gather audit trials and other information specific to the 
processing it performs in order to provide greater information 
gathering about VDE object usage. Providing multiple 



cooperating VDE electronic appliances 600 may also increase 
performance by eliminating the need to move encrypted 
information to a VDE electronic appliance 600 and then move it 
again in unencrypted form to a non-VDE device. The VDE- 
protected information can be moved directly to its destination 
device which, if VDE-capable, may directly process it without 
requiring involvement by some other VDE electronic appliance 
600. 

Figure 70 shows an example of an arrangement 2630 
comprising multiple VDE electronic appliances 600(1), 600(2), 
600(3), . . . , 600(N). VDE electronic appliances 600(1) . . . 600(N) 
may communicate with one another over a communications path 
2631 (e.g., the system bus of a work station, a telephone or other 
wire, a cable, a backplane, a network 672, or any other 
communications mechanism). Each of the electronic appliances 
600 shown in the figure may have the same general architecture 
shown in Figure 8, i.e., they may each include a CPU (or 
microcontroller) 654, SPU 500, RAM 656, ROM 658, and system 
bus 653. Each of the electronic appliances 600 shown in the 
figure may have an interface/controller 2632 (which may be 
considered to be a particular kind of I/O controller 660 and/or 
communications controller 666 shown in Figure 8). This 
interface/controller 2632 provides an interface between the 
electronic appliance system bus 653 and an appropriate electrical 



connector 2634. Electrical connectors 2634 of each of the 
respective electronic appliances 600(1), . . . 600(N) provide a 
connection to a common network 672 or other communication 
paths. 

Although each of electronic appliances 600 shown in the 
figure may have a generally similar architecture, they may 
perform different specialized tasks. For example, electronic 
appliance 600(1) might comprise a central processing section of a 
workstation responsible for managing the overall operation of the 
workstation and providing computation resources. Electronic 
appliance 600(2) might be a mass storage device 620 for the same 
workstation, and could provide a storage mechanism 2636 that 
might, for example, read information from and write information 
to a secondary storage device 652. Electronic appliance 600(3) 
might be a display device 614 responsible for performing display 
tasks, and could provide a displaying mechanism 2638 such as a 
graphics controller and associated video or other display. 
Electronic appliance 600(N) might be a printer 622 that performs 
printing related tasks and could include, for example, a print 
mechanism 2640. 

Each of electronic appliances 600(1), . . . 600(N) could 
comprise a different module of the same workstation device all 
contained within a common housing, or the different electronic 



appliances could be located within different system components. 
For example, electronic appliance 600(2) could be disposed within 
a disk controller unit, electronic appliance 600(3) could be 
disposed within a display device 614 housing, and the electronic 
appliance 600(N) could be disposed within the housing of a 
printer 622. Referring back to Figure 7, scanner 626, modem 
618, telecommunication means 624, keyboard 612 and/or voice 
recognition box 613 could each comprise a VDE electronic 
appliance 600 having its own SPU 500. Additional examples 
include RF or otherwise wireless interface controller, a serial 
interface controller, LAN controllers, MPEG (video) controllers, 
etc. 

Because electronic appliances 600(1) . . . 600(N) are each 
VDE-capable, they each have the ability to perform encryption 
and/or decryption of VDE-protected information. This means 
that information communicated across network 672 or other 
communications path 2631 connecting the electronic appliances 
can be VDE-protected (e.g., it may be packaged in the form of 
VDE administrative and/or content objects and encrypted as 
discussed above). One of the consequences of this arrangement is 
that an eavesdropper who taps into communications path 2631 
will not be able obtain information except in VDE-protected form. 
For example, information generated by electronic appliance 600 
(1) to be printed could be packaged in a VDE content object 300 
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and transmitted over path 2631 to electronic appliance 600 (N) 
for printing. An attacker would gain little benefit from 
intercepting this information since it is transmitted in protected 
form; she would have to compromise electronic appliance 600(1) 
or 600(N) (or the SPU 500(1), 500(N)) in order to access this 
information in unprotected form. 

Another advantage provided by the arrangement shown in 
the diagram is that each of electronic appliances 600(1), . . . 
600(N) may perform their own metering, control and/or other 
VDE-related functions. For example, electronic appliance 600(N) 
may meter and/or perform any other VDE control functions 
related to the information to be printed, electronic appliance 
600(3) may meter and/or perform any other VDE control 
functions related to the information to be displayed, electronic 
appliance 600(2) may meter and/or perform any other VDE 
control functions related to the information to be stored and/or 
retrieved from mass storage 620, and electronic appliance 600(1) 
may meter and/or perform any other VDE control functions 
related to the information it processes. 

In one specific arrangement, each of electronic appliances 
600(1), . 600(N) would receive a command that indicates that 
the information received by or sent to the electronic appliance is 
to use its SPU 500 to process the information to follow. For 
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example, electronic appliance 600(N) might receive a command 
that indicates that information it is about to receive for printing 
is in VDE-protected form (or the information that is sent to it 
may itself indicate this). Upon receiving this command or other 
information, electronic appliance 600(N) may decrypt the 
received information using SPU 500, and might also meter the 
information the SPU provides to the print mechanism 2644 for 
printing. An additional command might be sent to electronic 
appliance 600(N) to disable the decryption process or 600(N)'s 
VDE secure subsystem may determine that the information 
should not be decrypted and/or printed. Additional co mman ds, 
for example, may exist to load encryption/decryption keys, load 
limits," establish "fingerprinting" requirements, and read 
metered usage. These additional commands may be sent in 
encrypted or unencrypted form as appropriate. 

Suppose, for example, that electronic appliance 600(1) 
produces information it wishes to have printed by a VDE-capable 
printer 622. SPU 500(1) could establish a secure communications 
across path 2631 with SPU 500(N) to provide a command 
instructing SPU 500(N) to decrypt the next block of data and 
store it as a decryption key and a limit. SPU 500( 1) might then 
send a further command to SPU 500(N) to use the decryption key 
and associated limit to process any following encrypted print 
stream (or this command could be sent by CPU 654(1) to 



microcontroller 654(N)). Electronic appliance 600(1) could then 
begin sending encrypted information on path 672 for decryption 
and printing by printer 622. Upon receipt of each new block of 
information by printer 622, SPU 500(N) might first check to 
ensure that the limit is greater than zero. SPU 500(N) could 
then increment a usage meter value it maintains, and decrement 
the limit value. If the limit value is non-zero, SPU 500(N) could 
decrypt the information it has received and provide it to print 
mechanism 2640 for printing. If the limit is zero, then SPU 
500(N) would not send the received information to the print 
mechanism 2640, nor would it decrypt it. Upon receipt of a 
command to stop, printer 622 could revert to a n non-secure a mode 
in which it would print everything received by it across path 2631 
without permitting VDE processing. 

The SPU 500(N) associated with printer 622 need not 
necessarily be disposed within the housing of the printer, but 
could instead be placed within an I/O controller 660 for example 
(see Figure 8). This would allow at least some of the advantages 
similar to the ones discussed above to be provided without 
requiring a special VDE-capable printer 622. Alternatively, a 
SPU 500(N) could be provided both within printer 622 and within 
I/O controller 660 communicating with the printer to provide 
advantages in terms of coordinating I/O control and relieving 
processing burdens from the SPU 500 associated with the central 
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processing electronic appliance 600(1). When multiple VDE 
instances occur within an electronic appliance, one or more VDE 
secure subsystems may be "central" subsystems, that is 
"secondary'' VDE instances may pass encrypted usage related 
information to one or more central secure subsystems so as to 
allow said central subsystem to directly control storage of said 
usage related information. Certain control information may also 
be centrally stored by a central subsystem and all or a portion of 
such information may be securely provided to the secondary 
secure subsystem upon its secure VDE request. 

Portable Electronic Appliance 

Electronic appliance 600 provided by the present invention 
may be portable. Figure 71 shows one example of a portable 
electronic appliance 2600. Portable appliance 2600 may include 
a portable housing 2602 that may be about the size of a credit 
card in one example. Housing 2602 may connect to the outside 
world through, for example, an electrical connector 2604 having 
one or more electrical contact pins (not shown). Connector 2604 
may electrically connect an external bus interface 2606 internal 
to housing 2602 to a mating connector 2604a of a host system 
2608. External bus interface 2606 may, for example, comprise a 
PCMCIA (or other standard) bus interface to allow portable 
appliance 2600 to interface with and communicate over a bus 
2607 of host system 2608. Host 2608 may, for example, be almost 



any device imaginable, such as a computer, a pay telephone, 
another VDE electronic appliance 600, a television, an arcade 
video game, or a washing machine, to name a few examples. 

Housing 2602 may be tamper resistant. (See discussion 
above relating to tamper resistance of SPU barrier 502.) 

Portable appliance 2600 in the preferred embodiment 
includes one or more SPUs 500 that may be disposed within 
housing 2602. SPU 500 may be connected to external bus 
interface 2606 by a bus 2610 internal to housing 2602. SPU 500 
communicates with host 2608 (through external bus interface 
2606) over this internal bus 2610. 

SPU 500 may be powered by a battery 2612 or other 
portable power supply that is preferably disposed within housing 
2602. Battery 2612 may be, for example, a miniature battery of 
the type found in watches or credit card sized calculators. 
Battery 2612 may be supplemented (or replaced) by solar cells, 
rechargeable batteries, capacitive storage cells, etc. 

A random access memory (RAM) 2614 is preferably 
provided within housing 2602. RAM 2614 may be connected to 
SPU 500 and not directly connected to bus 2610, so that the 
contents of RAM 2614 may be accessed only by the SPU and not 



secure subsystem details as to the retail transaction (for example, 
what was purchased and price, the retail establishment's digital 
signature, the retail terminal's identifier, tax related information, 
etc.). 

For example, a host 2608 receptacle for receiving and/or 
attaching to portable appliance 2600 could be incorporated into 
or operatively connected to, a retail or other commercial 
establishment terminal The host terminal 2608 could be 
operated by either a commercial establishment employee or by 
the portable appliance 2600 holder. It could be used to, for 
example, input specific keyboard and/or voice input specific 
information such as who was taken to dinner, why something 
was purchased, or the category that the information should be 
attached to. Information could then be automatically "parsed" 
and routed into securely maintained (for example, encrypted) 
appropriate database management records within portable 
appliance 2600. Said "parsing" and routing would be securely 
controlled by VDE secure subsystem processes and could, for 
example, be based on category information entered in by the user 
and/or based on class of establishment and/or type (category) of 
expenditure information (or other use). Categorization can be 
provided by the retail establishment, for example, by securely 
communicating electronic category information as a portion, for 
example, of electronic receipt information or alternatively by 



and/or a key word, or other code that might cause the 
downloading of a transaction's detail into the portable appliance 
2600. This information might also be stored by the commercial 
establishment, and might also be communicated to the 
appropriate government and/or business organizations for 
validation of the reported transactions (the high level of security 
of auditing and communications and authentication and 
validation of VDE should be sufficiently trusted so as not to 
require the maintenance of a parallel audit history, but parallel 
maintenance may be supported, and maintained at least for a 
limited period of time so as to provide backup information in the 
event of loss or "failure" of portable appliance 2600 and/or one or 
more appliance 2600 associated VDE installations employed by 
appliance 2600 for historical and/or status information record 
maintenance). For example, of a retail terminal maintained 
necessary transaction information concerning a transaction 
involving appliance 2600, it could communicate such information 
to a clearinghouse for archiving (and/or other action) or it could 
periodically, for example, at the end of a business day, securely 
communicate such information, for example, in the form of a VDE 
content container object, to a clearinghouse or clearinghouse 
agent. Such transaction history (and any required VDE related 
status information such as available credit) can be maintained 
and if necessary, employed to reconstruct the information in a 
portable appliance 2600 so as to allow a replacement appliance to 



printing a hard copy receipt using printer 2624. This process of 
categorization may take place in the portable appliance 2600 or, 
alternatively, it could be performed by the retail establishment 
and periodically "rolled-up" and communicated to the portable 
appliance 2600 holder. 

Retail, clearinghouse, or other commercial organizations 
may maintain and use by securely communicating to appliance 
2600 one or more of generic classifications of transaction types 
(for example, as specified by government taxation rules) that can 
be used to automate the parsing of information into records 
and/or for database information "roll-ups" for; and/or in portable 
appliance 2600 or one or more associated VDE nodes. In such 
instances, host 2608 may comprise an auxiliary terminal, for 
example, or it could comprise or be incorporated directly within a 
commercial establishments cash registers or other retail 
transactions devices. The auxiliary terminal could be menu 
and/or icon driven, and allow very easy user selection of 
categorization. It could also provide templates, based on 
transaction type, that could guide the user through specifying 
useful or required transaction specific information (for example, 
purpose for a business dinner and/or who attended the dinner). 
For example, a user might select a business icon, then select from 
travel, sales, meals, administration, or purchasing icons for 
example, and then might enter in very specific information 



be provided to an appliance 2600 user or properly reset internal 
information in data wherein such replacement and/or resetting 
provides all necessary transaction and status information. 

In a retail establishment, the auxiliary terminal host 2608 
might take the form of a portable device presented to the user, for 
example at the end of a meal. The user might place his portable 
appliance 2600 into a smart card receptacle such as a PCMCIA 
slot, and then enter whatever additional information that might 
appropriately describe the transaction as well as satisfying 
whatever electronic appliance 600 identification procedure(s) 
required. The transaction, given the availability of sufficient 
credit, would be approved, and transaction related information 
would then be communicated back from the auxiliary terminal 
directly into the portable appliance 2600. This would be a highly 
convenient mode of credit usage and record management. 

The portable device auxiliary terminal might be "on-line," 
that is electronically communicating back to a commercial 
establishment and/or third party information collection point 
through the use of cellular, satellite, radio frequency, or other 
communications means. The auxiliary terminal might, after a 
check by a commercial party in response to receipt of certain 
identification information at the collection point, communicate 
back to the auxiliary terminal whether or not to accept the 



portable appliance 2600 based on other information, such as a 
bad credit record or a stolen portable appliance 2600. Such a 
portable auxiliary terminal would also be very useful at other 
commercial establishments, for example at gasoline stations, 
rental car return areas, street and stadium vendors, bars, and 
other commercial establishments where efficiency would be 
optimized by allowing clerks and other personnel to consummate 
transactions at points other than traditional cash register 
locations. 

As mentioned above, portable appliance 2600 may 
communicate from time to time with other electronic appliances 
600 such as, for example, a VDE administrator. Communication 
during a portable appliance 2600 usage session may result from 
internally stored parameters dictating that the connection should 
take place during that current session (or next or other session) 
of use of the portable appliance. The portable appliance 600 can 
carry information concerning a real-time date or window of time 
or duration of time that will, when appropriate, require the 
communication to take place (e.g., perhaps before the transaction 
or other process which has been contemplated by the user for 
that session or during it or immediately following it). Such a 
communication can be accomplished quickly, and could be a 
secure, VDE two-way communication during which information 
is communicated to a central information handler. Certain other 



information may be communicated to the portable appliance 2600 
and/or the computer or other electronic appliance to which the 
portable appliance 2600 has been connected. Such 
communicated other information can enable or prevent a 
contemplated process from proceeding, and/or make the portable 
appliance 2600, at least in part, unusable or useable. 
Information communicated to the portable appliance 2600 could 
include one or more modifications to permissions and methods, 
such as a resetting or increasing of one or more budgets, adding 
or withdrawing certain permissions, etc. 

The permissions and/or methods (i.e., budgets) carried by 
the portable appliance 2600 may have been assigned to it in 
conjunction with an "encumbering* 4 of another, stationary or 
other portable VDE electronic appliance 600. In one example, a 
portable appliance 2600 holder or other VDE electronic appliance 
600 and/or VDE electronic appliance 600 user could act as 
"guarantor" of the financial aspects of a transaction performed by 
another party. The portable appliance 2600 of the holder would 
record an "encumbrance,* which may be, during a secure 
communication with a clearinghouse, be recorded and 
maintained by the clearinghouse and/or some other financial 
services party until all or a portion of debt responsibilities of the 
other party were paid or otherwise satisfied. Alternatively or in 
addition, the encumbrance may also be maintained within the 



portable appliance 2600, representing the contingent obligation 
of the guarantor. The encumbrance may be, by some formula, 
included in a determination of the credit available to the 
guarantor. The credit transfer, acceptance, and/or record 
management, and related processes, may be securely maintained 
by the security features provided by aspects of the present 
invention. Portable appliance 600 may be the sole location for 
said permissions and/or methods for one or more VDE objects 
300, or it may carry budgets for said objects that are independent 
of budgets for said objects that are found on another, 
non-portable VDE electronic appliance 600. This may allow 
budgets, for example, to be portable, without requiring 
"encumbering" and budget reconciliation. 

Portable VDE electronic appliance 2600 may carry (as may 
other VDE electronic appliance 600s described) information 
describing credit history details, summary of authorizations, and 
usage history information (e.g., audit of some degree of 
transaction history or related summary information such as the 
use of a certain type/class of information) that allows re-use of 
certain VDE protected information at no cost or at a reduced cost. 
Such usage or cost of usage may be contingent, at least in part, 
on previous use of one or more objects or class of objects or 
.amount of use, etc., of VDE protected information. 



Portable appliance 2600 may also cany certain information 
which may be used, at least in part, for identification purposes. 
This information may be employed in a certain order (e.g. a 
pattern such as, for example, based on a pseudo-random 
algorithm) to verify the identity of the carrier of the portable 
appliance 2600. Such information may include, for example, 
one's own or a wife's and/or other relatives maiden names, social 
security number or numbers of one's own and/or others, birth 
dates, birth hospital(s), and other identifying information. It may 
also or alternatively provide or include one or more passwords or 
other information vised to identify or otherwise 
verify/authenticate an individual's identity, such as voice print 
and retinal scan information. For example, a portable appliance 
2600 can be used as a smart card that carries various 
permissions and/or method information for authorizations and 
budgets. This information can be stored securely within portable 
appliance 2600 in a secure database 610 arrangement. When a 
user attempts to purchase or license an electronic product or 
otherwise use the "smart card" to authorize a process, portable 
appliance 2600 may query the user for identification information 
or may initiate an identification process employing scanned or 
otherwise entered information (such as user fingerprint, retinal 
or voice analysis or other techniques that may, for example, 
employ mapping and/or matching of provided characteristics to 
information securely stored within the portable appliance 2600). 



The portable appliance 2600 may employ different queries at 
different times (and/or may present a plurality of queries or 
requests for scanning or otherwise entering identifying 
information) so as to prevent an individual who has come into 
possession of appropriate information for one or more of the 
"tests* of identity from being able to successfully employ the 
portable appliance 2600. 

A portable appliance 600 could also have the ability to 
transfer electronic currency or credit to another portable 
appliance 2600 or to another individual's account, for example, 
using secure VDE communication of relevant content between 
secure VDE subsystems. Such transfer may be accomplished, for 
example, by telecommunication to, or presentation at, a bank 
which can transfer credit and/or currency to the other account. 
The transfer could also occur by using two cards at the same 
portable appliance 2600 docking station. For example, a credit 
transaction workstation could include dual PCMCIA slots and 
appropriate credit and/or currency transfer application software 
which allows securely debiting one portable appliance 2600 and 
"crediting" another portable appliance (i.e., debiting from one 
appliance can occur upon issuing a corresponding credit and/or 
currency to the other appliance). One portable appliance 600, for 
example, could provide an authenticated credit to another user. 
Employing two "smart card" portable appliance 600 would enable 



the user of the providing of "credit" "smart card" to go through a 
transaction process in which said user provides proper 
identification (for example, a password) and identifies a "public 
key" identifying another "smart card" portable appliance 2600. 
The other portable appliance 2600 could use acceptance 
processes, and provide proper identification for a digital 
signature (and the credit and/or currency sender may also 
digitally sign a transaction certificate so the sending act may not 
be repudiated and this certificate may accompany the credit 
and/or currency as VDE container content. The transactions may 
involve, for example, user interface interaction that stipulates • 
interest and/or other terms of the transfer. It may employ 
templates for common transaction types where the provider of 
the credit is queried as to certain parameters describing the 
agreement between the parties. The receiving portable appliance 
2600 may iteratively or as a whole be queried as to the 
acceptance of the terms. VDE negotiation techniques described 
elsewhere in this application may be employed in a smart card 
transfer of electronic credit and/or currency to another VDE 
smart card or other VDE installation. 

Such VDE electronic appliance 600/portable appliance 
2600 credit transfer features would significantly reduce the 
overhead cost of managing certain electronic credit and/or 
currency activities by significantly automating these processes 



through extending the computerization of credit control and 
credit availability that was begun with credit cards and extended 
with debit cards. The automation of credit extension and/or 
currency transfer and the associated distributed processing 
advantages described, including the absence of any requirement 
for centralized processing and telecommunications during each 
transaction, truly make credit and/or currency, for many 
consumers and other electronic currency and/or credit users, an 
efficient, trusted, and portable commodity. 

The portable appliance 2600 or other VDE electronic 
appliance 600, can, in one embodiment, also automate many tax 
collection functions. A VDE electronic appliance 600 may, with 
great security, record financial transactions, identify the nature 
of the transaction, and identify the required sales or related 
government transaction taxes, debit the taxes from the users 
available credit, and securely communicate this information to 
one or more government agencies directly at some interval (for 
example monthly), and/or securely transfer this information to, , 
for example, a financial clearinghouse, which would then transfer 
one or more secure, encrypted (or unsecure, calculated by 
clearinghouse, or otherwise computed) information audit packets 
(e.g., VDE content containers and employing secure VDE 
communication techniques) to the one or more appropriate, 
participating government agencies. The overall integrity and 



security of VDE 100 could ensure, in a coherent and centralized 
manner, that electronic reporting of tax related information 
(derived from one or more electronic commerce activities) would 
be valid and comprehensive. It could also act as a validating 
source of information on the transfer of sales tax collection (e.g., 
if, for example, said funds are transferred directly to the 
government by a commercial operation and/or transferred in a 
manner such that reported tax related information cannot be 
tampered with by other parties in a VDE pathway of tax 
information handling). A government agency could select 
transactions randomly, or some subset or all of the reported 
transactions for a given commercial operation can be selected. 
This could be used to ensure that the commercial operation is 
actually paying to the government all appropriate collected funds 
required for taxes, and can also ensure that end-users are 
charged appropriate taxes for their transactions (including 
receipt of interest from bank accounts, investments, gifts, etc. 

Portable appliance 2600 financial and tax processes could 
involve template mechanisms described elsewhere herein. While 
such an electronic credit and/or currency management capability 
would be particularly interesting if managed at least in part, 
through the use of a portable appliance 2600, credit and/or 
currency transfer and similar features would also be applicable 
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for non-portable VDE electronic appliance 600's connected to or 
installed within a computer or other electronic device. 

User Notification Exception Interface ("Pop Up5 8 86 

As described above, the User Modification Exception 
Interface 686 may be a set of user interface programs for 
handling common VDE functions. These applications may be 
forms of VDE templates and are designed based upon certain 
assumptions regarding important options, specifically, 
appropriate to a certain VDE user model and important 
messages that must be reported given certain events A primary 
function of the "pop-up" user interface 686 is to provide a simple, 
consistent user interface to, for example, report metering events 
and exceptions (e.g., any condition for which automatic 
processing is either impossible or arguably undesirable) to the 
user, to enable the user to configure certain aspects of the 
operation of her electronic appliance 600 and, when appropriate, 
to allow the user to interactively control whether to proceed with 
certain transaction processes. If an object contains an exception 
handling method, that method will control how the "pop-up" user 
interface 686 handles specific classes of exceptions. 

The "pop-user" interface 686 normally enables handling of 
tasks not dedicated to specific objects 300, such as for example: 



Logging onto an electronic appliance 600 and/or entering 
into a VDE related activity or class of activities, 

Configuring an electronic appliance 600 for a registered 
user, and/or generally for the installation, with regard to 
user preferences, and automatic handling of certain types 
of exceptions, 

> Where appropriate, user selecting of meters for use with 
specific properties, and 

■ Providing an interface for communications with other 

electronic appliances 600, including requesting and/or for 
purchasing or leasing content from distributors, requesting 
clearinghouse credit and/or budgets from a clearinghouse, 
sending and/or receiving information to and/or from other 
electronic appliances, and so on. 

Figure 72A shows an example of a common "logon" VDE 
electronic appliance 600 function that may use user interface 
686. "Log-on" can be done by entering a user name, account 
name, and/or password. As shown in the provided example, a 
configuration option provided by the "pop-up" user interface 686 
dialog can be "Login at Setup", which, if selected, will initiate a 
VDE Login procedure automatically every time the user's 



WO 96/27155 



electronic appliance 600 is turned on or reset. Similarly, the 
"pop-up" user interface 686 could provide an interface option 
called "Login at Type" which, if selected, will initiate a procedure 
automatically every time, for example, a certain type of object or 
specific content type application is opened such as a file in a 
certain directory, a computer application or file with a certain 
identifying extension, or the like. 

Figure 72B shows an example of a "pop-up" user interface 
686 dialog that is activated when an action by the user has been 
"trapped," in this case to warn the user about the amount of 
expense that will be incurred by the user's action, as well as to 
alert the user about the object 300 which has been requested and 
what that particular object will cost to use. In this example, the 
interface dialog provides a button allowing the user to request 
further detailed information about the object, including full text 
descriptions, a list of associated files, and perhaps a history of 
past usage of the object including any residual rights to use the 
object or associated discounts. 

The "Cancel" button 2660 in Figure 72B cancels the user's 
trapped request. "Cancel" is the default in this example for this 
dialog and can be activated, for example, by the return and enter 
keys on the user's keyboard 612, by a "mouse dick" on that 
button, by voice command, or other command mechanisms. The 



"Approve button" 2662, which must be explicitly selected by a 
mouse click or other command procedure, allows the user to 
approve the expense and proceed. The "More options" control 
2664 expands the dialog to another level of detail which provides 
further options, an example of which is shown in Figure 72C. 

Figure 72C shows a secondary dialog that is presented to 
the user by the "pop-up" user interface 686 when the "More 
options" button 2664 in Figure 72B is selected by the user. As 
shown, this dialog includes numerous buttons for obtaining 
further information and performing various tasks. 

In this particular example, the user is permitted to set 
"limits" such as, for example, the session dollar limit amount 
(field 2666), a total transaction dollar limit amount (field 2668), a 
time limit (in minutes) (field 2670), and a "unit limit" (in number 
of units such as paragraphs, pages, etc.) (field 2672). Once the 
user has made her selections, she may "click on" the OKAY 
button (2674) to confirm the limit selections and cause them to 
take effect. 

Thus, pop-up user interface dialogues can be provided to 
specify user preferences, such as setting limits on budgets and/or 
other aspects of object content usage during any one session or 
over a certain duration of time or until a certain point in time. 



Dialogs can also be provided for selecting object related usage 
options such as selecting meters and budgets to be used with one 
or more objects. Selection of options may be applied to types 
(that is classes) of objects by associating the instruction with one 
or more identifying parameters related to the desired one or more 
types. User specified configuration information can set default 
values to be used in various situations, and can be used to limit 
the number or type of occasions on which the user's use of an 
object is interrupted by a w pop-up a interface 686 dialog. For 
example, the user might specify that a user request for VDE 
protected content should be automatically processed without 
interruption (resulting from an exceptions action) if the 
requested processing of information will not cost more than 
$25.00 and if the total charge for the entire current session 
(and/or day and/or week, etc.) is not greater than $200.00 and if 
the toted outstanding and unpaid charge for use hasn't exceeded 
$2500.00. 

Pop-up user interface dialogs may also be used to notify the 
user about significant conditions and events. For example, 
interface 686 may be used to: 

• remind the user to send audit information to a 
clearinghouse, 



• inform a user that a budget value is low and needs 
replenishing, 

• remind the user to back up secure database 610, and 

• inform the user about expirations of PERCs or other 
dates/times events. 

Other important "pop-up" user interface 686 functions 
include dialogs which enable flexible browsing through libraries 
of properties or objects available for licensing or purchase, either 
from locally stored VDE protected objects and/or from one or 
more various, remotely located content providers. Such function 
may be provided either while the user's computer is connected to 
a remote distributor's or clearinghouse's electronic appliance 600, 
or by activating an electronic connection to a remote source after 
a choice (such as a property, a resource location, or a class of 
objects or resources is selected). A browsing interface can allow 
this electronic connection to be made automatically upon a user 
selection of an item, or the connection itself can be explicitly 
activated by the user. See Figure 72D for an example of such a 
"browsing" dialog. 
Smart Objects 

VDE 100 extends its control capabilities and features to 
"intelligent agents." Generally, an "intelligent agent" can act as 
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an emissary to allow a process that dispatches it to achieve a 
result the originating process specifies. Intelligent agents that 
are capable of acting in the absence of their dispatch process are 
particularly useful to allow the dispatching process to access, 
through its agent, the resources of a remote electronic appliance. 
In such a scenario, the dispatch process may create an agent 
(e.g M a computer program and/or control information associated 
with a computer program) specifying a particular desired task(s), 
and dispatch the agent to the remote system. Upon reaching the 
remote system, the "agent" may perform its assigned task(s) 
using the remote system's resources. This allows the dispatch 
process to, in effect, extend its capabilities to remote systems 
where it is not present. 

Using an "agent" in this manner increases flexibility. The 
dispatching process can specify, through its agent, a particular 
desired task(s) that may not exist or be available on the remote 
system. Using such an agent also provides added trustedness; 
the dispatch process may only need to "trust" its agent, not the 
entire remote system. Agents have additional advantages. 

Software agents require a high level of control and 
accountability to be effective, safe and useful. Agents in the form 
• of computer viruses have had devastating effects worldwide. 
Therefore, a system that allows an agent to access it should be 



able to control it or otherwise prevent the agent from damaging 
important resources. In addition, systems allowing themselves to 
be accessed by an agent should sufficiently trust the agent and/or 
provide mechanisms capable of holding the true dispatcher of the 
agent responsible for the agent's activities. Similarly, the 
dispatching process should be able to adequately limit and/or 
control the authority of the agents it dispatches or else it might 
become responsible for unforeseen activities by the agent (e.g., 
the agent might run up a huge bill in the course of following 
imprecise instructions it was given by the process that dispatched 
it). 

These significant problems in using software agents have 
not be adequately addressed in the past. The open, flexible 
control structures provided by VDE 100 addresses these 
problems by providing the desired control and accountability for 
software agents (e.g., agent objects). For example, VDE 100 
positively controls content access and usage, provides guarantee 
of payment for content used, and enforces budget limits for 
accessed content. These control capabilities are well suited to 
controlling the activities of a dispatched agent by both the 
process that dispatches the agent and the resource accessed by 
the dispatched agent. 
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One aspect of the preferred embodiment provided by the 
present invention provides a "smart object" containing an agent. 
Generally, a "smart object* may be a VDE object 300 that 
contains some type(s) of software programs f agents*) for use 
with VDE control information at a VDE electronic appliance 600. 
A basic "smart object" may comprise a VDE object 300 that, for 
example, contains (physically and/or virtually): 

a software agent, and 

at least one rule and/or control associated with the 

software agent that governs the agent's operation. 
Although this basic structure is sufficient to define a "smart 
object,* Figure 73 shows a combination of containers and control 
information that provides one example of a particularly 
advantageous smart object structure for securely managing and 
controlling the operation of software agents. 

As shown in Figure 73, a smart object 3000 may be 
constructed of a container 300, within which is embedded one or 
more further containers (300z, 300y, etc.). Container 300 may 
further contain rules and control information for accessing and 
using these embedded containers 300z, 300y, etc. Container 300z 
embedded in container 300 is what makes the object 3000 a 
''smart object." It contains an "agent* that is managed and 
controlled by VDE 100. 



woyo/xviro 



The rules and control information 806f associated with 
container 3002 govern the circumstances under which the agent 
may be released and executed at a remote VDE site, including 
any limitations on execution based on the cost of execution for 
example. This rule and control information may be specified 
entirely in container 300z, and/or may be delivered as part of 
container 300, as part of another container (either within 
container 300 or a separately deliverable container), and/or may 
be already present at the remote VDE site. 

The second container 300y is optional, and contains 
content that describes the locations at which the agent stored in 
container 300z may be executed. Container 300y may also 
contain rules and control information 806e that describe the 
manner in which the contents of container 300y may be used or 
altered. This rule and control information 806e and/or further 
rules 300y(l) also contained within container 300y may describe 
searching and routing mechanisms that may be used to direct the 
smart object 3000 to a desired remote information resource. 
Container 300y may contain and/or reference rules and control 
information 300y(l) that specify the manner in which searching 
and routing information use and any changes may be paid for. 

Container 300x is an optional content container that is 
initially "empty" when the smart object 3000 is dispatched to a 
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remote site. It contains rules and control information 300x(l) for 
storing the content that is retrieved by the execution of the agent 
contained in container 300z. Container 300x may also contain 
limits on the value of content that is stored in the retrieval 
container so as to limit the amount of content that is retrieved. 

Other containers in the container 300 may include 
ao^ministrative objects that contain audit and billing trails that 
describe the actions of the agent in container 300z and any 
charges incurred for executing an agent at a remote VDE node. 
The exact structure of smart object 3000 is dependent upon the 
type of agent that is being controlled, the resources it will need 
for execution, and the types of information being retrieved. 

The smart object 3000 in the example shown in Figure 73 
may be used to control and manage the operation of an agent in 
VDE 100. The following detailed explanation of an example 
smart object transaction shown in Figure 74 may provide a 
helpful, but non-limiting illustration. In this particular example, 
assume a user is going to create a smart object 3000 that 
performs a library search using the "Very Fast and Efficient" 
software agent to search for books written about some subject of 
interest (e.g., "fire flies"). The search engine is designed to return 
a list of books to the user. The search engine in this example 
may spend no more than $10.00 to find the appropriate books, 



may spend no more than $3,00 in library access or 
communications charges to get to the library, and may retrieve 
no more than $15.00 in information. All information relating to 
the search or use is to be returned to the user and the user will 
permit no information pertaining to the user or the agent to be 
released to a third party. 

In this example, a dispatching VDE electronic appliance 
3010 constructs a smart object 3000 like the one shown in Figure 
73. The rule set in 806a is specified as a control set that contains 
the following elements: 

1. a smart_agent_execution event that specifies the 
smart agent is stored in embedded container 300z 
and has rules controlling its execution specified in 
that container; 

2. a smart_agent_use event that specifies the smart 
agent will operate using information and parameters 
stored in container 300; 

3. a routing_use event that specifies the information 
routing information is stored in container 300y and 
has rules controlling this information stored in that 
container; 



WO 96/27155 



4. an information write event that specifies 

information written will be stored in container 300y, 
300x, or 300w depending on its type (routing, 
retrieved, or administrative), and that these 
containers have independent roles that control how 
information is written into them. 

The rule set in control set 806b contains rules that specify 
the rights desired by this smart object 3000. Specifically, this 
control set specifies that the software agent desires: 

1. A right to use the "agent execution" service on the 
remote VDE site. Specific billing and charge 
information for this right is carried in container 
300z. 

2 A right to use the "software description list" service 
on the remote VDE site. Specific billing and charge 
information for this for this right is carried in 
container 300y. 

3 A right to use an "information locator service" on a 
remote VDE site. 



4. A right to have information returned to the user 
without charge (charges to be incurred on release of 
information and payment will be by a VISA budget) 

5. A right to have all audit information returned such 
that it is readable only by the sender. 

The rule set in control set 806c specifies that container 
300 w specifies the handling of all events related to its use. The 
rule set in control set 806d specifies that container 300x specifies 
the handling of all events related to its use. The rule set in 
control set 806e specifies that container 300y specifies the 
handling of all events related to its vise. The rule set in control 
set 806f specifies that container 300z specifies the handling of all 
events related to its use. 

Container 300z is specified as containing the "Very Fast 
and Efficient" agent content, which is associated with the 
following rules set: 

1. A use event that specifies a meter and VISA budget 
that limits the execution to $10.00 charged against 
the owner's VISA card. Audits of usage are required 
and will be stored in object 300w under control 
information specified in that object. 
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After container 300z and its set are specified, they are 
constructed and embedded in the smart object container 300. 

Container 300y is specified as a content object with two 
types of content. Content type A is routing information and is 
read/write in nature. Content type A is associated with a rules 
set that specifies: 

1. A use event that specifies no operation for the 
release of the content. This has the effect of not 
charging for the use of the content. 

2. A write event that specifies a meter and a VISA 
budget that limits the value of writing to $3.00. The 
billing method used by the write is left unspecified 
and will be specified by the control method that uses 
this rule. 

3. Audits of usage are required and will be stored in 
object 300w under control information specified in 
that object. 

Content type B is information that is used by the software 
agent to specify parameters for the agent. This content is 
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specified as the string "fire fly" or "fire flies". Content type B is 
associated with the following rule set: 

1. A use event that specifies that the use may only be 
by the software agent or a routing agent. The 
software agent has read only permission, the routing 
agent has read/write access to the information. 
There are no charges associated with using the 
information, but two meters; one by read and one by 
write are kept to track use of the information by 
various steps in the process. 

2. Audits of usage are required and will be stored in 
object 300w under control information specified in 
that object. 

After container 300y and its control sets are specified, they 
axe constructed and embedded in the smart object container 300. 

Container 300x is specified as a content object that is 
empty of content. It contains a control set that contains the 
following rules: 



1. A write.withoutjbilling event that specifies a meter 
and a general budget that limits the value of writing 
to $15.00. 

2. Audits of usage are required and will be stored in 
object 300w under control information specified in 
that object. 

3. An empty use control set that may be filled in by the 
owner of the information using predefined methods 
(method options). 

After container 300x and its control sets are specified, they 
constructed and embedded in the smart object container 300. 



Container 300w is specified as an empty administrative 
object with a control set that contains the following rules: 

1. A use event that specifies that the information 
contained in the administrative object may only be 
released to the creator of smart object container 300. 

2. No other rules may be attached to the administrative 
content in container 300w. 
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After container 300w and its control sets are specified, they 
are constructed and embedded in the smart object container 300. 

At this point, the smart object has been constructed and is 
ready to be dispatched to a remote VDE site. The smart object is 
sent to a remote VDE site (e.g., using electronic mail or another 
transport mechanism) that contains an information locator 
service 3012 via path 3014. The smart object is registered at the 
remote site 3012 for the "item locator service." The control set in 
container related to "item locator service" is selected and the 
rules contained within it activated at the remote site 3012. The 
remote site 3012 then reads the contents of container 300y under 
the control of rule set 806f and 300y(l), and permits writes of a 
list of location information into container 300y pursuant to these 
rules. The item locator service writes a list of three items into the 
smart object, and then "deregisters" the smart object (now 
containing the location information) and sends it to a site 3016 
specified in the list written to the smart object via path 3018. In 
this example, the user may have specified electronic mail for 
transport and a list of remote sites that may have the desired 
information is stored as a forwarding list. 

The smart object 3000, upon arriving at the second remote 
site 3016, is registered with that second site. The site 3016 
provides agent execution and software description list services 



compatible with VDE as a service to smart objects. It publishes 
these services and specifies that it requires $10.00 to start the 
agent and $20/piece for all information returned. The 
registration process compares the published service information 
against the rules stored within the object and determines that an 
acceptable overlap does not exist. Audit information for all these 
activities is written to the administrative object 300w. The 
registration process then fails (the object is not registered), and 
the smart object is forwarded by site 3016 to the next VDE site 
3020 in the list via path 3022. 

The smart object 3000, upon arriving at the third remote 
site 3020, is registered with that site. The site 3020 provides 
agent execution and software description list services compatible 
with VDE as a service to smart objects. It publishes these 
services and specifies that it requires $1.00 to start the agent and 
$0.50/piece for all information returned. The registration process 
compares the published service information against the rules 
stored within the object and determines that an acceptable 
overlap exists. The registration process creates a URT that 
specifies the agreed upon control information. This URT is used 
in conjunction with the other control information to execute the 
software agent under VDE control. 
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The agent software starts and reads its parameters out of 
container 300y. It then starts searching the database and 
obtains 253 "hits" in the database. The list of hits is written to 
container 300x along with a completed control set that specifies 
the granularity of each item and that each item costs $0.50. Upon 
completion of the search, the budget for use of the service is 
incremented by $1.00 to reflect the use charge for the service. 
Audit information for all these activities is written to the 
administrative object 300w. 

The remote site 3020 returns the now "lull" smart object 
3000 back to the original sender (the user) at their VDE node 
3010 via path 3024. Upon arrival, the smart object 3000 is 
registered and the database records are available. The control 
information specified in container 300x is now a mix of the 
original control information and the control information specified 
by the service regarding remote release of their information. The 
user then extracts 20 records from the smart object 3000 and has 
$10.00 charged to her VISA budget at the time of extraction. 

In the above smart agent VDE examples, a certain 
organization of smart object 3000 and its constituent containers 
is described. Other organizations of VDE and smart object 
related control information and parameter data may be. created 
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and may be used for the same purposes as those ascribed to 
object 3000 in the above example. 

Negotiation and Electronic Contracts 

An electronic contract is an electronic form of an 
agreement including rights, restrictions, and obligations of the 
parties to the agreement. In many cases, electronic agreements 
may surround the use of digitally provided content; for example, 
a license to view a digitally distributed movie. It is not required, 
however, that an electronic agreement be conditioned on the 
presence or use of electronic content by one or more parties to the 
agreement. In its simplest form, an electronic agreement 
contains a right and a control that governs how that right is 
used. 

Electronic agreements, like traditional agreements, may be 
negotiated between their parties (terms and conditions submitted 
by one or more parties may simply be accepted (cohesion 
contract) by one or more other parties and/or such other parties 
may have the right to select certain of such terms and conditions 
(while others may be required)). Negotiation is defined in the 
dictionary as "the act of bringing together by mutual agreement." 
The preferred embodiment provides electronic negotiation 
processes by which one or more rights and associated controls can 
be established through electronic automated negotiation of terms. 
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Negotiations normally require a precise specification of rights 
and controls associated with those rights. PERC and URT 
structures provide a mechanism that may be used to provide 
precise electronic representations of rights and the controls 
associated with those rights. VDE thus provides a "vocabulary" 
and mechanism by which users and creators may specify their 
desires. Automated processes may interpret these desires and 
negotiate to reach a common middle ground based on these 
desires. The results of said negotiation may be concisely 
described in a structure that may be used to control and enforce 
the results of the electronic agreement. VDE further enables this 
process by providing a secure execution space in which the 
negotiation process(es) are assured of integrity and 
confidentiality in their operation. The negotiation process(es) 
may also be executed in such a manner that inhibits external 
tampering with the negotiation. 

A final desirable feature of agreements in general (and 
electronic representations of agreements in particular) is that 
they be accurately recorded in a non-repudiatable form. In 
traditional terms, this involves creating a paper document (a 
contract) that describes the rights, restrictions, and obligations of 
all parties involved. This document is read and then signed by 
all parties as being an accurate representation of the agreement. 
Electronic agreements, by their nature, may not be initially 
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rendered in paper. VDE enables such agreements to be 
accurately electronically described and then electronically signed 
to prevent repudiation. In addition, the preferred embodiment 
provides a mechanism by which human-readable descriptions of 
terms of the electronic contract can be provided. 

VDE provides a concise mechanism for specifying control 
sets that are VDE site interpretable. Machine interpretable 
mechanisms are often not human readable. VDE often operates 
the negotiation process on behalf of at least one human user. It 
is thus desirable that the negotiation be expressible in "human 
readable form." VDE data structures for objects, methods, and 
load modules all have provisions to specify one or more DTDs 
within their structures. These DTDs may be stored as part of the 
item or they may be stored independently. The DTD describes 
one or more data elements (MDE, UDE, or other related data 
elements) that may contain a natural language description of the 
function of that item. These natural language descriptions 
provide a language independent, human readable description for 
each item. Collections of items (for example, a BUDGET method) 
can be associated with natural language text that describes its 
function and forms a term of an electronically specified and 
enforceable contract. Collections of terms (a control set) define a 
contract associated with a specific right. VDE thus permits the 
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electronic specification, negotiation, and enforcement of electronic 
contracts that humans can understand and adhere to. 



VDE 100 enables the negotiation and enforcement of 
electronic contracts in several ways: 



• it enables a concise specification of rights and control 
information that permit a common vocabulary and 
procedure for negotiation, 

• it provides a secure processing environment within 
which to negotiate, 

• it provides a distributed environment within which 
rights and control specifications may be securely 
distributed, 

• it provides a secure processing environment in which 
negotiated contracts may be electronically rendered 
and signed by the processes that negotiate them, and 

• it provides a mechanism that securely enforces a 
negotiated electronic contract. 
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Types of Negotiations 

A simple form of a negotiation is a demand by one party to 
form an "adhesion" contract. There are few, if any, options that 
may be chosen by the other party in the negotiation. The 
recipient of the demand has a simple option; she may accept or 
reject the terms and conditions (control information) in the 
demand. If she accepts the conditions, she is granted rights 
subject to the specified control information. If she rejects the 
conditions, she is not granted the rights. PERC and URT 
structures may support negotiation by demand; a PERC or 
control set from a PERC may be presented as a demand, and the 
recipient may accept or reject the demand (selecting any 
permitted method options if they are presented). 

A common example of this type of negotiation today is the 
purchase of software under the terms of a "shrink-wrap license." 
Many widely publicized electronic distribution schemes use this 
type of negotiation. CompuServe is an example of an on-line 
service that operates in the same manner. The choice is simple: 
either pay the specified charge or don't use the service or 
software. VDE supports this type of negotiation with its 
capability to provide PERCs and URTs that describe rights and 
control information, and by permitting a content owner to provide 
a REGISTER method that allows a user to select from a set of 
predefined method options. In this scenario, the REGISTER 
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method may contain a component that is a simplified negotiation 
process. 

A more complex form of a negotiation is analogous to 
"haggling." In this scenario, most of the terms and conditions are 
fixed, but one or more terms (e.g., price or payment terms) are 
not. For these terms, there are options, limits, and elements that 
may be negotiated over. A VDE electronic negotiation between 
two parties may be used to resolve the desired, permitted, and 
optional terms. The result of the electronic negotiation may be a 
finalized set of rules and control information that specify a 
completed electronic contract. A simple example is the scenario 
for purchasing software described above adding the ability of the 
purchaser to select a method of payment (VISA, Mastercard, or 
American Express). A more complex example is a scenario for 
purchasing information in which the price paid depends on the 
amount of information about the user that is returned along with 
a usage audit trail. In this second example, the right to use the 
content may be associated with two control sets. One control set 
may describe a fixed ("higher") price for using the content. 
Another control set may describe a fixed ("lower") price for using 
the content with additional control information and field 
specifications requiring collection and return the user's personal 
information. In both of these cases, the optional and permitted 
fields and control sets in a PERC may describe the options that 



WO 96/27155 



may be selected as part of the negotiation. To perform the 
negotiation, one party may propose a control set containing 
specific fields, control information, and limits as specified by a 
PERC; the other party may pick and accept from the control sets 
proposed, reject them, or propose alternate control sets that 
might be used. The negotiation process may use the permitted, 
required, and optional designations in the PERC to determine an 
acceptable range of parameters for the final rule set. Once an 
agreement is reached, the negotiation process may create a new 
PERC and/or URT that describes the result of the negotiation. 
The resulting PERCs and/or URTs may be "signed" (e.g., using 
digital signatures) by all of the negotiation processes involved in 
the negotiation to prevent repudiation of the agreement at a later 
date. 

Additional examples of negotiated elements are: electronic 
cash, purchase orders, purchase certificates (gift certificates, 
coupons), bidding and specifications, budget "rollbacks" and 
reconciliation, currency exchange rates, stock purchasing, and 
billing rates, 

A set of PERCs that might be used to support the second 
example described above is presented in Figures 75A (PERC sent 
by the content owner), 75B (PERC created by user to represent 
their selections and rights), and 75C (PERC for controlling the 
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negotiation process). These PERCs might be used in conjunction 
with any of the negotiation process(es) and protocols described 
later in this section. 

Figure 75A shows an example of a PERC 3100 that might 
be created by a content provider to describe their rights options. 
In this example, the PERC contains information regarding a 
single USE right. Two alternate control sets 3102a, 3102b are 
presented for this right in the example. Control set 3102a 
permits the use of the content without passing back information 
about the user, and another control set 3102b permits the use of 
the content and collects "response card" type information from 
the user. Both control sets 3102a, 3102b may use a common set 
of methods for most of the control information. This common 
control information is represented by a CSR 3104 and CS0 3106. 

Control set 3102a in this PERC 3100 describes a 
mechanism by which the user may obtain the content without 
providing any information about its user to the content provider. 
This control set 3102a specifies a well-known vending control 
method and set of required methods and method options. 
Specifically, in this example, control set 3102a defines a 
BUDGET method 3108 (e.g., one of VISA, Mastercard, or 
American Express) and it defines a BILLING method 3110 that 
specifies a charge (e.g., a one-time charge of $100.00). 
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Control set 3102b in this PERC 3100 describes another 
mechanism by which the user may obtain the content. In this 
example, the control set 3102b specifies a different vending 
control method and a set of required methods and method 
options. This second control set 3102b specifies a BUDGET 
method 3112 (e.g., one of VISA, Mastercard, or American 
Express), a BILLING method 3116 that specifies a charge (e.g., a 
lesser one-time charge such as $25.00) and an AUDIT method 
3114 that specifies a set of desired and required fields. The 
required and desired field specification 3116 may take the form of 
a DTD specification, in which, for example, the field names are 
listed. 

The content creator may "prefer" one of the two control sets 
(e.g., control set 2) over the other one. If so, the "preferred" 
control set may be "offered" first in the negotiation process, and 
withdrawn in favor of the "non-preferred" control set if the other 
party to the negotiation "rejects" the "preferred" control set. 

In this example, these two control sets 3102a, 3102b may 
share a common BUDGET method specification. The BUDGET 
method specification may be included in the CSR 3104 or CS0 
3106 control sets if desired. Selecting control set 3102a (use with 
no information passback) causes a unique component assembly to 
be assembled as specified by the PERC 3100. Specifically, in this 
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example it selects the "Vending" CONTROL method 3118, the 
BILLING method 3110 for a $100 fixed charge, and the rest of 
the control information specified by CSR 3104 and CSO 3106. It 
also requires the user to specify her choice of acceptable 
BUDGET method (e.g., from the list including VISA, Mastercard, 
and American Express). Selecting control set 3102b assembles a 
different component assembly using the "Vending with 'response 
card'" CONTROL method 3120, the BILLING method 3116 (e.g., 
for a $25 fixed charge), an AUDIT method 3114 that requires the 
fields listed in the Required Fields DTD 3116. The process may 
also select as many of the fields listed in the Desired Fields DTD 
3116 as are made available to it. The rest of the control 
information is specified by CSR 3104 and CSO 3106. The 
selection of control set 3102b also forces the user to specify their 
choice of acceptable BUDGET methods (e.g., from the list 
including VISA, Mastercard, and American Express). 

Figure 75B shows an example of a control set 3125 that 
might be used by a user to specify her desires and requirements 
in a negotiation process. This control set has a USE rights 
section 3127 that contains an aggregated CSR budget 
specification 3129 and two optional control sets 3131a, 3131b for 
use of the content. Control set 3131a requires the use of a 
specific CONTROL method 3133 and AUDIT method 3135. The 
specified AUDIT method 3135 is parameterized with a list of 
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fields 3137 that may be released in the audit trail. Control set 
3131a also specifies a BILLING method 3139 that can cost no 
more than a certain amount (e.g., $30.00). Control set 3131b in 
this example describes a specific CONTROL method 3141 and 
may reference a BILLING method 3143 that can cost no more 
than a certain amount (e.g., $150.00) if this option is selected. 

Figure 75E shows a more high-level view of an electronic 
contract 3200 formed as a "result" of a negotiation process as 
described above. Electronic contract 3200 may include multiple 
clauses 3202 and multiple digital signatures 3204. Each clause 
3202 may comprise a PERC/URT such as item 3160 described 
above and shown in Figure 75D. Each "clause" 3202 of electronic 
contract 3200 thus corresponds to a component assembly 690 
that may be assembled and executed by a VDE electronic 
appliance 600. Just as in normal contracts, there may be as 
many contract clauses 3202 within electronic contract 3200 as is 
necessary to embody the "agreement" between the "parties." 
Each of clauses 3202 may have been electronically negotiated 
and may thus embody a part of the "agreement" (e.g., a 
"compromise") between the parties. Electronic contract 3200 is 
"self-executing" in the sense that it may be literally executed by a 
machine, i.e„ a VDE electronic appliance 600 that assembles 
component assemblies 690 as specified by various electronic 
clauses 3202. Electronic contract 3200 may be automatically 
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"enforced" using the same VDE mechanisms discussed above that 
are used in conjunction with any component assembly 690. For 
example, assuming that a clause 3202(2) corresponds to a 
payment or BILLING condition or term, its corresponding 
component assembly 690 when assembled by a user's VDE 
electronic appliance 600 may automatically determine whether 
conditions are right for payment and, when they are, 
automatically access an appropriate payment mechanism (e.g., a 
virtual "credit card" object for the user) to arrange that payment 
to be made. As another example, assuming that electronic 
contract clause N 3202(N) corresponds to a user's obligation to 
provide auditing information to a particular VDE participant, 
electronic contract 3200 will cause VDE electronic appliance 600 
to assemble a corresponding component assembly 690 that may, 
for example, access the appropriate audit trails within secure 
database 610 and provide them in an administrative object to the 
correct participant. Figure 75F shows that clause 3202(N) may, 
for example, specify a component assembly 690 that arranges for 
multiple steps in a transaction 3206 to occur. Some of these steps 
(e.g., step 3208(4), 3208(5)) may be conditional on a test (e.g., 
3208(3)) such as, for example, whether content usage has 
exceeded a certain amount, whether a certain time period has 
expired, whether a certain calendar date has been reached, etc. 
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Digital signatures 3204 shown in the Figure 75E electronic 
contract 3200 may comprise, for example, conventional digital 
signatures using public key techniques as described above. Some 
electronic contracts 3200 may not bear any digital signatures 
3204. However, it may be desirable to require the electronic 
appliance 600 of the user who is a party to the electronic contract 
3200 to digitally "sign" the electronic contract so that the user 
cannot later repudiate the contract, for evidentiary purposes, etc. 
Multiple parties to the same contract may each digitally "sign" 
the same electronic contract 3200 similarly to the way multiple 
parties to a contract memorialized in a written instrument use an 
ink pen to sign the instrument. 

Although each of the clauses 3202 of electronic contract 
3200 may ultimately correspond to a collection of data and code 
that may be executed by a PPE 650, there may in some instances 
be a need for rendering a human readable version of the 
electronic contract. This need can be accommodated by, as 
mentioned above, providing text within one or more DTDs 
associated with the component assembly or assemblies 690 used 
to "self-execute" the contract. Such text might, for example, 
describe from a functional point of view what the corresponding 
electronic contract clause 3202 means or involves, and/or might 
describe in legally enforceable terms what the legal obligation 
under the contract is or represents. "Templates" (described 



elsewhere herein) might be used to supply such text from a text 
library. An expert system and/or artificial intelligence capability 
might be used to impose syntax rules that bind different textual 
elements together into a coherent, humanly readable contract 
document. Such text could, if necessary, be reviewed and 
modified by a "human" attorney in order customize it for the 
particular agreement between the parties and/or to add further 
legal obligations augmenting the "self-executing" electronic 
obligations embodied within and enforced by the associated 
component assemblies 690 executing on a VDE electronic 
appliance 600. Such text could be displayed automatically or on 
demand upon execution of the electronic contract, or it could be 
used to generate a printed humanly-readable version of the 
contract at any time. Such a document version of the electronic 
contract 3200 would not need to be signed in ink by the parties to 
the agreement (unless desired) in view of the fact that the digital 
signatures 3204 would provide a sufficiently secure and trusted 
evidentiary basis for proving the parties' mutual assent to all the 
terms and conditions within the contract. 

In the preferred embodiment, the negotiation process 
executes within a PPE 650 under the direction of a further PERC 
that specifies the process. Figure 75C shows an example of a 
PERC 3150 that specifies a negotiation process. The PERC 3150 
contains a single right 3152 for negotiation, with two permitted 
control sets 3154a, 3154b described for that right. The first 



employ in a variety of other applications such as, for example, 
commercial applications. The portable electronic appliance 2600 
may, for example, cany permission and/or method information 
used to authorize (and possibly record) commercial processes and 
services. 

An advantage of using the preferred embodiment VDE 
portable appliance 2600 for financial transactions such as those 
typically performed by banks and credit card companies is that 
VDE allows financial clearinghouses (such as VISA, MasterCard, 
or American Express) to experience significant reductions in 
operating costs. The clearinghouse reduction in costs result from 
the fact that the local metering and budget management that 
occurs at the user site through the use of a VDE electronic 
appliance 600 such as portable appliance 2600 frees the 
clearinghouse from being involved in every transaction. In 
contrast to current requirements, clearinghouses will be able to 
perform their functions by periodically updating their records 
(such as once a month). Audit and/or budget "roll-ups" may occur 
during a connection initiated to communicate such audit and/or 
budget information and/or through a connection that can occur at 
periodic or relatively periodic intervals and/or during a credit 
updating, purchasing, or other portable appliance 2600 
transaction. 



Clearinghouse VDE digital distribution transactions would 
require only occasional authorization and/or audit or other 
administrative "roll-ups" to the central service, rather than far 
more costly connections during each session. Since there would 
be no requirement for the maintenance of a credit card purchase 
"paper trail" (the authorization and then forwarding of the credit 
card slip), there could be substantial cost reductions for 
clearinghouses (and, potentially, lower costs to users) due to 
reduction in communication costs, facilities to handle concurrent 
processing of information, and paper handling aspects of 
transaction processing costs. This use of a portable appliance 
2600 would allow credit enforcement to exploit distributed 
processing employing the computing capability in each VDE 
electronic appliance 600. These credit cost and processing 
advantages may also apply to the use of non-smart card and 
non-portable VDE electronic appliance 600s. 



Since VDE 100 may be configured as a highly secure 
commercial environment, and since the authentication processes 
supported by VDE employ digital signature processes which 
provide a legal validation that should be equivalent to paper 
documentation and handwritten signatures, the need for portable 
appliance 2600 to maintain paper trails, even for more costly 
transactions, is eliminated. Since auditable billing and control 
mechanisms are built into VDE 100 and automated, they may 



replace traditional electronic interfaces to VISA, Master Card, 
AMEX, and bank debit accounts for digitally distributed other 
products and services, and may save substantial operating costs 
for such clearinghouses. 

Portable appliance 2600 may, if desired, maintain for a 
consumer a portable electronic history. The portable history can 
be, for example, moved to an electronic "dock" or other receptacle, 
in or operatively connected to, a computer or other consumer host 
appliance 2608. Host appliance 2608 could be, for example, an 
electronic organizer that has control logic at least in part in the 
form of a microcomputer and that stores information in an 
organized manner, e.g., according to tax and/or other transaction 
categories (such as type of use or activity). By use of this 
arrangement, the consumer no longer has to maintain receipts or 
otherwise manually track transactions but nevertheless can 
maintain an electronic, highly secure audit trail of transactions 
and transaction descriptions. The transaction descriptions may, 
for example, securely include the user's digital signature, and 
optionally, the service or goods provider's digital signature. 

When a portable appliance 2600 is "docked" to a host 2608 
such as a personal computer or other electronic appliance (such 
as an electronic organizer), the portable appliance 2600 could 
communicate interim audit information to the host. In one 
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complex. It may utilize artificial intelligence, fuzzy logic, and/or 
related algorithms to reach their goals. VDE supports these 
types of processes by providing a mechanism for concisely 
specifying rights, control information, fields and goals (in the 
form of desired rights, control information, and fields). Goals for 
these types of processes might be specified as one more control 
sets that contain specific elements that are tagged as optional, 
permitted, or desired. 

Types of Negotiations 

Negotiations in the preferred embodiment may be 
structured in any of the following ways: 

1. shared knowledge 

2. trusted negotiator 

3 . "zero-based" knowledge 

"Shared knowledge" negotiations are based on all parties 
knowing all of the rules and constraints associated with the 
negotiation. Demand negotiations are a simple case of shared 
knowledge negotiations; the demander presents a list of demands 
that must be accepted or rejected together. The list of demands 
comprises a complete set of knowledge required to accept or reject 
each item on the list. VDE enables this class of negotiation to 
occur electronically by providing a mechanism by which .demands 
may be encoded, securely passed, and securely processed between 
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and with secure VDE subsystems using VDE secure processing, 
and communication capabilities. Other types of shared 
knowledge negotiations employed by VDE involve the exchange 
of information between two or more negotiating parties; the 
negotiation process(es) can independently determine desired final 
outcome(s) based on their independent priorities. The processes 
can then negotiate over any differences. Shared knowledge 
negotiations may require a single negotiation process (as in a 
demand type negotiation) or may involve two or more cooperative 
processes. Figures 76A and 76B illustrate scenarios in which one 
and two negotiation processes are used in a shared knowledge 
negotiation. 

Figure 76A shows a single negotiation process 3172 that 
takes any number of PERCs 808 (e.g., supplied by different 
parties) as inputs to the negotiation. The negotiation process 
3172 executes at a VDE node under supervision of "Negotiation 
Process Rules and Control information" that may be supplied by 
a further PERC (e.g., PERC 3150 shown in Figure 75C). The 
process 3172 generates one or more PERCs/URTs 3160 as results 
of the negotiation. 

Figure 76B shows multiple negotiation processes 3172A- 
3172N each of which takes as input a PERC 808 from a party 
and a further PERC 3150 that controls the negotiation process, 



and each of which generates a negotiated "result" PERC/URT 
3160 as output. Processes 3172A-3172N may execute at the 
same or different VDE nodes and may communicate using a 
"negotiation protocol." 

Single and multiple negotiation processes may he used for 
specific VDE sites. The negotiation processes are named, and can 
be accessed using well known method names. PERCs and URTs 
may be transported in administrative or smart objects to remote 
VDE sites for processing at that site, as may the control PERCs 
and REGISTER method that controls the negotiation. 

Multiple negotiation processes require the ability to 
communicate between these processes 3172; including secure 
communication between secure processes that are present at 
physically separate VDE sites (secure subsystems). VDE 
generalizes the inter-process communication into a securely 
provided service that can be used if the configuration requires it. 
The inter-process communication uses a negotiation protocol to 
exchange information about rule sets between processes 3172. 
An example of a negotiation protocol includes the following 
negotiation primitives*: 

WANT Want a set of terms and conditions 

ACCEPT Accept a set of terms and conditions 

REJECT Reject a set of terms and conditions 
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OFFER Offer a set of terms and conditions in 

exchange for other terms and conditions 
HAVE Assert a set of terms and conditions are 

possible or desirable 
QUIT Assert the end of the negotiation 

without reaching an agreement 
AGREEMENT Conclude the negotiation and pass the 

rule set for signature 

The WANT primitive takes rights and control set (or parts 
of control sets) information, and asserts to the other process(es) 
3172 that the specified terms are desired or required. Demand 
negotiations are a simple case of a WANT primitive being used to 
assert the demand. This example of a protocol may introduce a 
refined form of the WANT primitive, REQUIRE. In this example, 
REQUIRE allows a parly to set terms that she decides are 
necessary for a contract to be formed, WANT may allow the party 
to set terms that are desirable but not essential. This permits a 
distinction between "must have" and "would like to have." 

In this example, WANT primitives must always be 
answered by an ACCEPT, REJECT, or OFFER primitive. The 
ACCEPT primitive permits a negotiation process 3172 to accept a 
set of terms and conditions. The REJECT primitive permits a 
process 3172 to reject an offered set of terms and conditions. 
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Rejecting a set of required terms and conditions may terminate 
the negotiation. OFFER permits a counter-offer to be made. 

The HAVE, QUIT, and AGREEMENT primitives permit 
the negotiation protocols to pass information about rule sets. 
Shared knowledge negotiations may, for example, start with all 
negotiation processes 3172A-3172N asserting HAVE (my PERC) 
to the other processes. HAVE is also used when an impasse is 
reached and one process 3172 needs to let the other process 3172 
know about permitted options. QUIT signals an unsuccessful 
end of the negotiation without reaching an agreement, while 
AGREEMENT signals a successful end of an agreement and 
passes the resulting "negotiated" PERC/URT 3160 to the other 
process(es) 3172 for signature. 

In "trusted negotiator" negotiations, all parties provide 
their demands and preferences to a "trusted" negotiator and 
agree to be bound by her decision. This is similar to binding 
arbitration in today's society. VDE enables this mode of 
negotiation by providing an environment in which a "trusted" 
negotiation service may be created. VDE provides not only the 
mechanism by which demands, desires, and limits may be 
concisely specified (e.g., in PERCs), but in which the PERCs may 
be securely transferred to a "trusted" negotiation service along 
with a rule set that specifies how the negotiation will be 
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conducted, and by providing a secure execution environment so 
that the negotiation process may not be tampered with. Trusted 
negotiator services can be used at VDE sites where the integrity 
of the site is well known. Remote trusted negotiation services 
can be used by VDE sites that do not possess sufficient 
computing resources to execute one or more negotiation 
process(es); they can establish a communication link to a VDE 
site that provides this service and permits the service to handle 
the negotiation on their behalf. 

"Zero-based" knowledge negotiations share some 
characteristics of the zero-based knowledge protocols used for 
authentication. It is well understood in the art how to construct 
a protocol that can determine if a remote site is the holder of a 
specific item without exchanging or exposing the item. This type 
of protocol can be constructed between two negotiation processes 
operating on at least one VDE site using a control set as their 
knowledge base. The negotiation processes may exchange 
information about their control sets, and may make demands and 
counter proposals regarding using their individual rule sets. For 
example, negotiation process A may communicate with 
negotiation process B to negotiate rights to read a book. 
Negotiation process A specifies that it will pay not more than 
$10^00 for rights to read the book, and prefers to pay between 
$5.00 and $6.00 for this right. Process A's rule set also specifies 



that for the $5.00 option, it will permit the release of the reader's 
name and address. Process B's rule set specifies that it wants 
$50.00 for rights to read the book, and will provide the book for 
$5.50 if the user agrees to release information about himself. The 
negotiation might go something like this: 

Process A <— > Process B 

Want (right to read, unrestricted) — > 

< — Have(right to read, 
unrestricted, $50) 

Offer (right to read, tender 

user info) — > 

< — Have(right to read, 
tender user info, 
$5.50) 

Accept(right to read, tender 
user info, $5.50) > 



In the above example, process A first specifies that it 
desires the light to read the book without restrictions or other 
information release. This starting position is specified as a rights 
option in the PERC that process A is using as a rule. Process B 
checks its rules and determines that an unrestricted right to read 
is indeed permitted for a price of $50. It replies to process A that 
these terms are available. Process A receives this reply and 
checks it against the control set in the PERC it uses as a rule 
" base. The $50 is outside the $10 limit specified for this control 
set, so Process A cannot accept the offer. It makes a counter offer 



(as described in another optional rights option) of an unrestricted 
right to read coupled with the release of the reader's name and 
address. The name and address fields are described in a DTD 
referenced by Process A's PERC. Process B checks its rules 
PERC and determines that an unrestricted right to read 
combined with the release of personal information is a permitted 
option. It compares the fields that would be released as described 
in the DTD provided by Process A against the desired fields in a 
DTD in its own PERC, and determines an acceptable match has 
occurred. It then sends an offer for unrestricted rights with the 
release of specific information for the cost of $5.50 to Process A. 
Process A compares the right, restrictions, and fields against its 
rule set and determines that $5.50 is within the range of $5-$6 
described as acceptable in its rule set. It accepts the offer as 
made. The offer is sealed by both parties "signing" a new PERC 
that describes the results of the final negotiation (unrestricted 
rights, with release of user information, for $5.50). The new 
PERC may be used by the owner of Process A to read the content 
(the book) subject to the described terms and conditions. 

Further Chain of Handling Model 

As described in connection with Figure 2, there are four (4 > 
"participant" instances of VDE 100 in one example of a VDE 
• chain of handling and control used, for example, for content 
distribution. The first of these participant instances, the content 
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creator 102, is manipulated by the publisher, author, rights 
owner or distributor of a literary property to prepare the 
information for distribution to the consumer. The second 
participant instance, VDE rights distributor 106, may distribute 
rights and may also administer and analyze customers' use of 
VDE authored information. The third participant instance, 
content user 112, is operated by users (included end-users and 
distributors) when they use information. The fourth participant 
instance, financial clearinghouse 116 enables the VDE related 
clearinghouse activities. A further participant, a VDE 
administrator, may provide support to keep VDE 100 operating 
properly. With appropriate authorizations and Rights Operating 
System components installed, any VDE electronic appliance 600 
can play any or all of these participant roles. 

Literary property is one example of raw material for VDE 
100. To transfer this raw material into finished goods, the 
publisher, author, or rights owner uses tools to transform digital 
information (such as electronic books, databases, computer 
software and movies) into protected digital packages called 
"objects" Only those consumers (or others along the chain of 
possession such as a redistributor) who receive permission from a 
distributor 106 can open these packages. VDE packaged content 
can be constrained by "rules and control information" provided by 
content creator 102 and/or content distributor 106— or by other 
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VDE participants in the content's distribution pathway, Le., 
normally by participants "closer" to the creation of the VDE 
secured package than the participant being constrained. 

Once the content is packaged in an "object," the digital 
distribution process may begin. Since the information packages 
themselves are protected, they may be freely distributed on CD- 
ROM disks, through computer networks, or broadcast through 
cable or by airwaves. Informal "out of channel" exchange of 
protected packages among end-users does not pose a risk to the 
content property rights. This is because only authorized 
individuals may use such packages. In fact, such "out of channel" 
distribution may be encouraged by some content providers as a 
marginal cost method of market penetration. Consumers with 
usage authorizations (e.g., a VISA clearinghouse budget allowing 
a certain dollar amount of usage) may, for example, be free to 
license classes of out of channel VDE protected packages 
provided to them, for example, by a neighbor. 

To open a VDE package and make use of its content, an 
end-user must have permission. Distributors 106 can grant these 
permissions, and can very flexibly (if permitted by senior control 
information) limit or otherwise specify the ways in which package 
contents may be used. Distributors 106 and financial 
clearinghouses 116 also typically have financial responsibilities 
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(they may be the same organization in some circumstances if 
desired). They ensure that any payments required from end- 
users fulfill their own and any other participant's requirements. 
This is achieved by auditing usage. 

Distributors 106 using VDE 100 may include software 
publishers, database publishers, cable, television, and radio 
broadcasters, and other distributors of information in electronic 
form. VDE 100 supports all forms of electronic distribution, 
including distribution by broadcast or telecommunications, or by 
the physical transfer of electronic storage media. It also supports 
the delivery of content in homogeneous form, seamlessly 
integrating information from multiple distribution types with 
separate delivery of permissions, control mechanisms and 
content. 

Distributors 106 and financial clearinghouses 116 may 
themselves be audited based on secure records of their 
administrative activities and a chain of reliable, "trusted" 
processes ensures the integrity of the overall digital distribution 
process. This allows content owners, for example, to verify that 
they are receiving appropriate compensation based on actual 
content usage or other agreed-upon bases. 

Since the end-user 112 is the ultimate consumer of content 
in this example, VDE 100 is designed to provide protected 
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content in a seamless and transparent way— so long as the end- 
user stays within the limits of the pennissions she has received. 
The activities of end-user 112 can be metered so that an audit 
can be conducted by distributors 106. The auditing process may 
be filtered and/or generalized to satisfy user privacy concerns. 
For example, metered, recorded VDE content and/or appliance 
usage information may be filtered prior to reporting it to 
distributor 106 to prevent more information than necessary from 
being revealed about content user 112 and/or her usage. 

VDE 100 gives content providers the ability to recreate 
important aspects of their traditional distribution strategies in 
electronic form and to innovatively structure new distribution 
mechanisms appropriate to their individual needs and 
circumstances. VDE 100 supports relevant participants in the 
chain of distribution, and also enables their desired pricing 
strategies, access and redistribution pennissions, usage rules, 
and related administrative and analysis procedures. The 
reusable functional primitives of VDE 100 can be flexibly 
combined by content providers to reflect their respective 
distribution objectives. As a result, content providers can feed 
their information into established distribution channels and als 
create their own personalized distribution channels. 



WO 9UZ7133 



A summary of the roles of the various participants of 
virtual distribution environment 100 is set forth in the table 
below: 



Role 


Description 


TraditionalTarticinants 


Content creator 


Packager and initial distributor of digital 
information 


Content owner 


Owner of the digital information. 


Distributors 


Provide rights distribution services for budgets 
and/or content. 


Auditor 


rToviaes services ior processing ana reducing 
usage based audit trails. 


Clearinghouse 


Provides intermediate store and forward services 
for content and audit information. Also, typically 
provides a platform for other services, including 
third party financial providers and auditors. 


Network provider 


Provides communication services between sites 
and other participants. 


Financial providers 


Provider of third party sources of electronic funds 
to end-users and distributors. Examples of this 
class of users are VISA, American Express, or a 
government. 


End Users 


Consumers of information. 


Other Particioante 


Redistributor 


Redistributes rights to use content based on chain 
of handling restrictions from content providers 
and/or other distributors. 


VDE Administrator 


Provider of trusted services for support of VDE 
nodes. 
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Role 


Description a 


Tm/4AT\0ThrfpTit Audit 

| TiQCpcXAvACJ-iv ******** v 

Processor 


Provider of services for processing and 
summarizing audit trail data. Provides anonymity 
to end-users while maintaining the comprehensive 
audit capabilities required by the content 
providers. m 


Agents 


Provides distributed presence for end-users and 
nther VDE participants. 



Of these various VDE participants, the "redistributor," 
"VDE Administrator," "independent audit processor" and 
"agents" are, in certain respects "new" participants that may 
have no counterpart in many "traditional" business models. The 
other VDE participants (i.e., content provider, content owner, 
distributors, auditor, clearinghouse, network provider and 
financial providers) have "traditional" business model 
counterparts in the sense that traditional distribution models 
often included non-electronic participants performing some of the 
same business roles they serve in the virtual distribution 
environment 100. 



VDE distributors 106 may also include "end-users" who 
provide electronic information to other end-users. For example, 
Figure 77 shows a further example of a virtual distribution 
environment 100 chain of handling and control provided by the 
present invention. As compared to Figure 2, Figure 77 includes a 
j "client administrator" participant 700. In addition, Figure 



new 



77 shows several different content users 112(1), 112(2), . . . , 
112(n) that may all be subject to the "jurisdiction 41 of the client 
administrator 700. Client administrator 700 may be, for 
example, a further rights distributor within a corporation or 
other organization that distributes rights to employees or other 
organization participant units (such as divisions, departments, 
networks, and or groups, etc.) subject to organization-specific 
"rules and control information.** The client administrator 700 
may fashion rules and control information for distribution, 
subject to "rules and control" specified by creator 102 and/or 
distributor 106. 

As mentioned above, VDE administrator 116b is a trusted 
VDE node that supports VDE 100 and keeps it operating 
properly. In this example, VDE administrator 116b may provide, 
among others, any of all of the following: 

• VDE appliance initialization services 

• VDE appliance reinitializationAipdate services 

• Key management services 

• "Hot lists" of "rogue* VDE sites 

• Certification authority services 

• Public key registration 

• Client participant unit content budgets and other 
authorizations 
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All participants of VDE 100 have the innate ability to 
participate in any role. For example, users may gather together 
existing protected packages, add (create new content) packages of 
their own, and create new products. They may choose to serve as 
their own distributor, or delegate this responsibility to others. 
These capabilities are particularly important in the object 
oriented paradigm which is entering the marketplace today. The 
production of compound objects, object linking and embedding, 
and other multi-source processes will create a need for these 
capabilities of VDE 100. The distribution process provided by 
VDE 100 is symmetrical; any end-user may redistribute 
information received to other end-users, provided they possess 
permission from and follow the rules established by the 
distribution chain VDE control information governing 
redistribution. End-users also may, within the same rules and 
permissions restriction, encapsulate content owned by others 
within newly published works and distribute these works 
independently. Royalty payments for the new works may be 
accessed by the publisher, distributors, or end-users, and may be 
tracked and electronically collected at any stage of the chain. 

Independent financial providers can play an important role 
in VDE 100. The VDE financial provider role is similar to the 
role played by organizations such as VISA in traditional 
distribution scenarios. In any distribution model, authorizing 



payments for use of products or services and auditing usage for 
consistency and irregularities, is critical. In VDE 100, these are 
the roles filled by independent financial providers. The 
independent financial providers may also provide audit services 
to content providers. Thus, budgets or limits on use, and audits, 
or records of use, may be processed by (and may also be put in 
place by) clearinghouses 116, and the clearinghouses may then 
collect usage payments from users 112. Any VDE user 112 may 
assign the right to process information or perform services on 
their behalf to the extend allowed by senior control information. 
The arrangement by which one VDE participant acts on behalf of 
another is called a "proxy." Audit, distribution, and other 
important rights may be "proxied" if permitted by the content 
provider. One special type of "proxy" is the VDE administrator 
116b. A VDE administrator is an organization (which may be 
acting also as a financial clearinghouse 116) that has permission 
to manage (for example, "intervene" to reset) some portion or all 
of VDE secure subsystem control information for VDE electronic 
appliances. This administration right may extend only to 
admitting new appliances to a VDE infrastructure and to 
recovering "crashed" or otherwise inoperable appliances, and 
providing periodic VDE updates. 
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More On Object Creation, Distribution Methods, Budgets, and 
Audits 

VDE node electronic appliances 600 in the preferred 
embodiment can have the ability to perform object creation, 
distribution, audit collection and usage control functions provided 
by the present invention. Incorporating this range of capabilities 
within each of many electronic appliances 600 provided by the 
preferred embodiment is important to a general goal of creating a 
single (or prominent) standard for electronic transactions 
metering, control, and billing, that, in its sum of installations, 
constitutes a secure, trusted, virtual transaction/distribution 
management environment. If, generally speaking, certain key 
functions were generally or frequently missing, at least in 
general purpose VDE node electronic appliances 600, then a 
variety of different products and different standards would come 
forth to satisfy the wide range of applications for electronic 
transaction/distribution management; a single consistent set of 
tools and a single "rational," trusted security and commercial 
distribution environment will not have been put in place to 
answer the pressing needs of the evolving "electronic highway." 
Certain forms of certain electronic appliances 600 containing 
VDE nodes which incorporate embedded dedicated VDE 
microcontrollers such as certain forms of video cassette players, 
cable television converters and the like may not necessarily have 
or need full VDE capabilities. However, the preferred 



embodiment provides a number of distributed, disparately 
located electronic appliances 600 each of which desirably include 
authoring, distribution, extraction, audit, and audit reduction 
capabilities, along with object authoring capabilities. 

The VDE object authoring capabilities provided by the 
preferred embodiment provides an author, for example, with a 
variety of menus for incorporating methods in a VDE object 300, 
including: 

• menus for metering and/or billing methods which 

define how usage of the content portion of a 
VDE object is to be controlled, 

• menus related to extraction methods for limiting 

and/or enabling users of a VDE object from 
extracting information from that object, and 
may include placing such information in a 
newly created and/or pre-existing VDE content 
container,, 

• menus for specifying audit methods — that is, 

whether or not certain audit information is to be 
generated and communicated in some secure 
fashion back to an object provider, object 
creator, administrator, and/or clearinghouse, 
and 
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• menus for distribution methods for controlling 
how an object is distributed, including for 
example, controlling distribution rights of 
different participant's "down" a VDE chain of 
content container handling. 
The authoring capabilities may also include procedures for 
distributing administrative budgets, object distribution control 
keys, and audit control keys to distributors and other VDE 
participants who are authorized to perform distribution and/or 
auditing functions on behalf of the author, distributors, and/or 
themselves. The authoring capabilities may also include 
procedures for selecting and distributing distribution methods, 
audit methods and audit reduction methods, including for 
example, securely writing and/or otherwise controlling budgets 
for object redistribution by distributors to subsequent VDE chain 
of content handling participants. 

The content of an object 300 created by an author may be 
generated with the assistance of a VDE aware application 
program or a non-VDE aware application program. The content 
of the object created by an author in conjunction with such 
programs may include text, formatted text, pictures, moving 
pictures, sounds, computer software, multimedia, electronic 
games, electronic training materials, various types of files, and so 
on, without limitation. The authoring process may encapsulate 



content generated by the author in an object, encrypt the content 
with one or more keys, and append one or more methods to define 
parameters of allowed use and/or required auditing of use and/or 
payment for use of the object by users (and/or by authorized users 
only). The authoring process may also include some or all aspects 
of distributing the object. 

In general, in the preferred embodiment, an author can: 

A. Specify what content is to be included in an 

object. 

B. Specify content oriented methods including: 

Information-typically abstract, promotional, 
identifying, scheduling, and/or other 
information related to the content and/or 
author 

Content— e.g. list of files and/or other 
information resources containing content, time 
variables, etc. 

C. Specify control information (typically a collection 

of methods related to one another by one or 
more permissions records, including any method 
defining variables) and any initial authorized 
user list including, for example: 
Control information over Access & Extraction 
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Control information over Distribution 
Control information over Audit Processing 

A VDE node electronic appliance 600 may, for example, 
distribute an object on behalf of an object provider if a VDE node 
receives from an object provider administrative budget 
information for distributing the object and associated distribution 
key information. 

A VDE node electronic appliance 600 may receive and 
process audit records on behalf of an object provider if that VDE 
node receives any necessary administrative budget, audit 
method, and audit key information (used, for example, to decrypt 
audit trails), from the object provider. An auditing-capable VDE 
electronic appliance 600 may control execution of audit reduction 
methods. "Audit reduction" in the preferred embodiment is the 
process of extracting information from audit records and/or 
processes that an object provider (e.g., any object provider along a 
chain of handling of the object) has specified to be reported to an 
object's distributors, object creators, client administrators, and/or 
any other user of audit information. This may include, for 
example, advertisers who may be required to pay for a user's 
usage of object content. In one embodiment, for example, a 
clearinghouse can have the ability to "append" budget, audit 
method, and/or audit key information to an object or class or 
other grouping of objects located at a user site or located at an 



object provider site to ensure that desired audit processes will 
take place in a "trusted" fashion. A participant in a chain of 
handling of a VDE content container and/or content container 
control information object may act as a "proxy* for another party 
in a chain of handling of visage auditing information related to 
usage of object content (for example a clearinghouse, an 
advertiser, or a party interested in market survey and/or specific 
customer usage information). This may be done by specifying, for 
that other party, budget, audit method, and/or key information 
that may be necessary to ensure audit information is gathered 
and/or provided to, in a proper manner, said additional party. 
For example, employing specification information provided by 
said other party. 

Object Creation and Initial Control Structures 

The VDE preferred embodiment object creation and control 
structure design processes support fundamental configurability 
of control information. This enables VDE 100 to support a full 
range of possible content types, distribution pathways, usage 
control information, auditing requirements, and users and user 
groups. VDE object creation in the preferred embodiment 
employs VDE templates whose atomic elements represent at 
least in part modular control processes. Employing VDE creation 
software (in the preferred embodiment a GUI programming 
process) and VDE templates, users may create VDE objects 300 
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by, for example, partitioning the objects, placing "meta data" 
(e.g., author's name, creation date, etc.) into them, and assigning 
rights associated with them and/or object content to, for example, 
a publisher and/or content creator. When an object creator runs 
through this process, she normally will go through a content 
specification procedure which will request required data. The 
content specification process, when satisfied, may proceed by, for 
example, inserting data into a template and encapsulating the 
content. In addition, in the preferred embodiment, an object may 
also automatically register its presence with the local VDE node 
electronic appliance 600 secure subsystem, and at least one 
permissions record 808 may be produced as a result of the 
interaction of template instructions and atomic methods, as well 
as one or more pieces of control structure which can include one 
or more methods, budgets, and/or etc. A registration process may 
require a budget to be created for the object. If an object creation 
process specifies an initial distribution, an administrative object 
may also be created for distribution The aojninistrative object 
may contain one or more permission records 808, other control 
structures, methods, and/or load modules. 

Permissions records 808 may specify various control 
relationships between objects and users. For example, VDE 100 
supports both single access (e.g., one-to-one relationship between 
a user and a right user) and group access (any number of people 



may be authorized as a group). A single permissions record 808 
can define both single and group access. VDE 100 may provide 
"sharing," a process that allows multiple users to share a single 
control budget as a budget. Additional control structure concepts 
include distribution, redistribution, and audit, the latter 
supporting meter and budget information reduction and/or 
transfer. All of these processes are normally securely controlled 
by one or more VDE secure subsystems. 

Templates and Glasses 

VDE templates, classes, and flexible control structures 
support frameworks for organizations and individuals that 
create, modify, market, distribute, redistribute, consume, and 
otherwise use movies, audio recordings and live performances, 
magazines, telephony based retail sales, catalogs, computer 
software, information databases, multimedia, commercial 
communications, advertisements, market surveys, infomercials, 
games, CAD/CAM services for numerically controlled machines, 
and the like. As the context surrounding these classes changes 
or evolves, the templates provided by the preferred embodiment 
of the present invention can be modified to meet these changes 
for broad use, or more focused activities. 

VDE 100 authoring may provide three inputs into a create 
process: Templates, user input and object content. Templates 



act as a set of control instructions and/or data for object control 
software which are capable of creating (and/or modifying) VDE 
objects in a process that interacts with user instructions and 
provided content to create a VDE object. Templates are usually 
specifically associated with object creation and/or control 
structures. Classes represent user groups which can include 
"natural" groups within an organization, such as department 
members, specific security clearance levels, etc., or ad hoc lists of 
individual's and/or VDE nodes. 

For example, templates may be represented as text files 
defining specific structures and/or component assemblies. 
Templates, with their structures and/or component assemblies 
may serve as VDE object authoring or object control applications. 
A creation template may consist of a number of sub-templates, 
which, at the lowest level, represent an "atomic level" of 
description of object specification. Templates may present one or 
more models that describe various aspects of a content object and 
how the object should be created including employing secure 
atomic methods that are used to create, alter, and/or destroy 
permissions records 808 and/or associated budgets, etc. 

Templates, classes (including user groups employing an 
. object under group access), and flexible control structures 
including object "independent" permissions records (permissions 



that can be associated with a plurality of objects) and structures 
that support budgeting and auditing as separate VDE processes, 
help focus the flexible and configurable capabilities inherent 
within authoring provided by the present invention in the context 
of specific industries and/or businesses and/or applications. VDE 
rationalizes and encompasses distribution scenarios currently 
employed in a wide array of powerful industries (in part through 
the use of application or industry specific templates). Therefore, 
it is important to provide a framework of operation and/or 
structure to allow existing industries and/or applications and/or 
businesses to manipulate familiar concepts related to content 
types, distribution approaches, pricing mechanisms, user 
interactions with content and/or related administrative activities, 
budgets, and the like. 

The VDE templates, classes, and control structures are 
inherently flexible and configurable to reflect the breadth of 
information distribution and secure storage requirements, to 
allow for efficient adaptation into new industries as they evolve, 
and to reflect the evolution and/or change of an existing industry 
and/or business, as well as to support one or more groups of users 
who may be associated with certain permissions and/or budgets 
and object types. The flexibility of VDE templates, classes, and 
basic control structures is enhanced through the use of VDE 
aggregate and control methods which have a compound, 
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conditional process impact on object control. Taken together, and 
employed at times with VDE administrative objects and VDE 
security arrangements and processes, the present invention truly 
achieves a content control and auditing architecture that can be 
configured to most any commercial distribution embodiment. 
Thus, the present invention fully supports the requirements and 
biases of content providers without forcing them to fit a 
predefined application model It allows them to define the rights, 

control information, and flow of their content (and the return of 

audit information) through distribution channels. 

Modifying Object Content (Adding, Hiding, Modifying, Removing, 
and/or Extending) 

Adding new content to objects is an important aspect of 
authoring provided by the present invention. Providers may 
wish to allow one or more users to add, hide, modify, remove 
and/or extend content that they provide. In this way, other users 
may add value to, alter for a new purpose, maintain, and/or 
otherwise change, existing content. The ability to add content to 
an empty and/or newly created object is important as well 

When a provider provides content and accompanying 
control information, she may elect to add control information that 
enables and/or limits the addition, modification, hiding and/or 
deletion of said content. This control information may concern: 



the nature and/or location of content that may be 
added, hidden, modified, and/or deleted; 

portions of content that may be modified, hidden, 
deleted and/or added to; 

required secure control information over 
subsequent VDE container content usage in a 
chain of control and/or locally to added, hidden, 
and/or modified content; 

requirements that provider-specified notices 
and/or portions of content accompany added, 
hidden, deleted and/or modified content and/or 
the fact that said adding, hiding, modification 
and/or deletion occurred; 

secure management of limitations and/or 
requirements concerning content that may be 
removed, hidden and/or deleted from content, 
including the amount and/or degree of addition, 
hiding, modification and/or deletion of content; 

providing notice to a provider or providers that 
modification, hiding, addition and/or deletion 
has occurred and/or the nature of said 
occurrence; and 

other control information concerned with 
modification, addition, hiding, and/or deleting 
provider content. 



A provider may use this control information to establish an 
opportunity for other users to add value to and/or maintain 
existing content in a controlled way. For example, a provider of 
software development tools may allow other users to add 
commentary and/or similar and/or complementary tools to their 
provided objects. A provider of movies may allow commentary 
and/or promotional materials to be added to their materials. A 
provider of CAD/CAM specifications to machine tool owners may 
allow other users to modify objects containing instructions 
associated with a specification to improve and/or translate said 
instructions for use with their equipment. A database owner 
may allow other users to add and/or remove records from a 
provided database object to allow flexibility and/or maintenance 
of the database. 

Another benefit of introducing control information is the 
opportunity for a provider to allow other users to alter content for 
a new purpose. A provider may allow other users to provide 
content in a new setting. 

To attach this control information to content, a provider 
may be provided with, or if allowed, design and implement, a 
method or methods for an object that govern addition, hiding, 
modification and/or deletion of content. Design and 
implementation of such one or more methods may be performed 
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using VDE software tools in combination with a PPE 650. The 
provider may then attach the method(s) to an object and/or 
provide them separately. A permissions record 808 may include 
requirements associated with this control information in 
combination with other control information, or a separate 
permissions record 808 may be used. 

An important aspect of adding or modifying content is the 
choice of encryption/decryption keys and/or other relevant 
aspects of securing new or altered content. The provider may 
specify in their method(s) associated with these processes a 
technique or techniques to be used for creating and/or selecting 
the encryption/decryption keys and/or other relevant aspect of 
securing new and/or altered content. For example, the provider 
may include a collection of keys, a technique for generating new 
keys, a reference to a load module that will generate keys, a 
protocol for securing content, and/or other similar information. 

Another i mp ortant implication is the management of new 
keys, if any are created and/or used. A provider may require that 
such keys and reference to which keys were used must be 
transmitted to the provider, or she may allow the keys and/or 
securing strategy to remain outside a provider's knowledge 
. and/or control. A provider may also choose an intermediate 
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course in which some keys must be transmitted and others may 
remain outside her knowledge and/or control. 

An additional aspect related to the management of keys is 
the management of permissions associated with an object 
resulting from the addition, hiding, modification and/or deletion 
of content. A provider may or may not allow a VDE chain of 
control information user to take some or all of the VDE rules and 
control information associated with gran t ing permissions to 
access and/or manipulate VDE managed content and/or rules and 
control information associated with said resulting object. For 
example, a provider may allow a first user to control access to 
new content in an object, thereby requiring any other user of that 
portion of content to receive permission from the first user. This 
may or may not, at the provider's discretion, obviate the need for 
a user to obtain permission from the provider to access the object 
at all. 

Keys associated with addition, modification, hiding and/or 
deletion may be stored in an independent permissions record or 
records 808. Said permissions record(s) 808 may be delivered to a 
provider or providers and potentially merged with an existing 
permissions record or records, or may remain solely under the 
control of the new content provider. The creation and content of 
an initial permissions record 808 and any control information 
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over the permissions record(s) are controlled by the method(s) 
associated with activities by a provider. Subsequent modification 
and/or use of said permission record(s) may involve a provider's 
method(s), user action, or both. A user's ability to modify and/or 
use permissions record(s) 808 is dependent on, at least in part, 
the senior control information associated with the permissions 
record(s) of a provider. 

Distribution Control information 

To enable a broad and flexible commercial transaction 
environment, providers should have the ability to establish firm 
control information over a distribution process without unduly 
limiting the possibilities of subsequent parties in a chain of 
control. The distribution control information provided by the 
present invention allow flexible positive control. No provider is 
required to include any particular control, or use any particular 
strategy, except as required by senior control information. 
Rather, the present invention allows a provider to select from 
generic control components (which may be provided as a subset of 
components appropriate to a provider's specific market, for 
example, as included in and/or directly compatible with, a VDE 
application) to establish a structure appropriate for a given chain 
of handling/controb A provider may also establish control 
information on their control information that enable and limit 
modifications to their control information by other users. 
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The administrative systems provided by the present 
invention generate administrative "events.- These "events- 
correspond to activities initiated by either the system or a user 
that correspond to potentially protected processes within VDE. 
These processes include activities such as copying a permissions 
record, copying abudget, reading an audit trail record, copying a 
method, updating a budget, updating a permissions record, 
updating a method, backing up management files, restoring 
management files, and the like. Reading, writing, modifying, 
updating, processing, and/or deleting information from any 
portion of any VDE record may be administrative events. An 
administrative event may represent a process that performs one 
or more of the aforementioned activities on one or more portions 
of one or more records. 

When a VDE electronic appliance 600 encounters an 
administrative event, that event is typically processed in 
conjunction with a VDE PPE 650. As in the case of events 
generally related to access and/or use of content, in most cases 
adniinistrative events are specified by content providers 
(including, for example, content creators, distributors, and/or 
client administrators) as an aspect of a control specified for an 
object, group and/or class of objects. 



For example, if a user initiates a request to distribute 
permission to use a certain object from a desktop computer to a 
notebook computer, one of the administrative events generated 
may be to create a copy of a permissions record that corresponds 
to the object. When this administrative event is detected by ROS 
602, an EVENT method for this type of event may be present. If 
an EVENT method is present, there may also be a meter, a 
billing, and a budget associated with the EVENT method. 
Metering, billing, and budgeting can allow a provider to enable 
and limit the copying of a permissions record 808. 



For example, during the course of processing a control 
program, a meter, a billing, and a budget and/or audit records 
may be generated and/or updated. Said audit records may record 
information concerning circumstances surrounding an 
administrative event and processing of said event. For example, 
an audit record may contain a reference to a user and/or system 
activity that initiated an event, the success or failure of 
processing said event, the date and/or time, and/or other relevant 
information. 

Referring to the above example of a user with both a 
desktop and notebook computer, the provider of a permissions 
record may require an audit record each time a meter for copying 
said permissions record is processed. The audit record provides a 
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flexible and configurable control and/or recording environment 
option for a provider. 

In some circumstances, it may be desirable for a provider 
to limit which aspects of a control component may be modified, 
updated, and/or deleted. "Atomic element definitions" may be 
used to limit the applicability of events (and therefore the 
remainder of a control process, if one exists) to certain "atomic 
elements" of a control component. For example, if a permissions 
record 808 is decomposed into "atomic elements" on the fields 
described in Figure 26, an event processing chain may be limited, 
for example, to a certain number of modifications of expiration 
date/time information by specifying only this field in an atomic 
element definition. In another example, a permissions record 808 
may be decomposed into atomic elements based on control sets. 
In this example, an event chain may be limited to events that act 
upon certain control sets. 

In some circumstances, it may be desirable for a provider 
to control how administrative processes are performed. The 
provider may choose to include in distribution records stored in 
secure database 610 information for use in conjunction with a 
component assembly 690 that controls and specifies, for example, 
how processing for a given event in relation to a given method 
and/or record should be performed. For example, if a provider 
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wishes to allow a user to make copies of a permissions record 808, 
she may want to alter the permissions record internally. For 
example, in the earlier example of a user with a desktop and a 
notebook computer, a provider may allow a user to make copies of 
information necessary to enable the notebook computer based on 
information present in the desktop computer, but not allow any 
further copies of said information to be made by the notebook 
VDE node. In this example, the distribution control structure 
described earlier would continue to exist on the desktop 
computer, but the copies of the enabling information passed to 
the notebook computer would lack the required distribution 
control structure to perform distribution from the notebook 
computer. Similarly, a distribution control structure may be 
provided by a content provider to a content provider who is a 
distributor in which a control structure would enable a certain 
number of copies to be made of a VDE content container object 
along with associated copies of permissions records, but the 
permissions records would be altered (as per specification of the 
content provider, for example) so as not to allow end-users who 
received distributor created copies from making further copies for 
distribution to other VDE nodes. 

Although the preceding example focuses on one particular 
event (copying) under one possible case, similar processes may be 
used for reading, writing, modifying, updating, processing, 



and/or deleting information from records and/or methods under 
any control relationship contemplated by the present invention. 
Other examples include: copying a budget, copying a meter, 
updating a budget, updating a meter, condensing an audit trail, 
and the like. 

Creating Custom Methods 

In the preferred embodiment of the present invention, 
methods may be created "at will,* 4 or aliased to another method. 
These two modes contribute to the superior configurability, 
flexibility, and positive control of the VDE distribution process. 
Generally, creating a method involves specifying the required 
attributes or parameters for the data portion of the method, and 
then "typ ing " the method. The typing process typically involves 
choosing one or more load modules to process any data portions of 
a method. In addition to the method itself, the process of method 
creation may also result in a method option subrecord for 
inclusion in, or modification of, a permissions record, and a 
notation in the distribution records. In addition to any 
"standard* load module(s) required for exercise of the method, 
additional load modules, and data for use with those load 
modules, may be specified if allowed. These event processing 
structures control the distribution of the method. 



For example, consider the case of a security budget. One 
form of a typical budget might limit the user to 10Mb of 
decrypted data per month. The user wishes to move their rights 
to use the relevant VDE content container object to their 
notebook. The budget creator might have limited the notebook to 
the same amount, half the original amount, a prorated amount 
based on the number of moves budgeted for an object, etc. A 
distribute method (or internal event processing structure) 
associated with the budget allows the creator of the budget to 
make a determination as to the methodology and parameters 
involved. Of course, different distribution methods may be 
required for the case of redistribution, or formal distribution of 
the method. The aggregate of these choices is stored in a 
permissions record for the method. 

An example of the process steps used for the move of a 
budget record might look something like this: 

1) Check the move budget (e.g., to determine the 

number of moves allowed) 

2) Copy static fields to new record (e.g., as an 
encumbrance) 

3) Decrement the Deer counter in the old record (the 

original budget) 

4) Increment the Encumbrance counter in the old 

record 
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5) Write a distribution record 

6) Write a Distribution Event Id to the new record 

7) Increment the move meter 

8) Decrement the move budget 

9) Increment the Deer counter in the new record 

Creating a Budget 

In the preferred embodiment, to create a budget, a user 
manipulates a Graphical User Interface budget distribution 
application (e.g., a VDE template application). The user fills out 
any required fields for type(s) of budget, expiration cycle(s), 
auditors), etc. A budget may be specified in dollars, deutsche 
marks, yen, and/or in any other monetary or content 
measurement schema and/or organization. The preferred 
embodiment output of the application, normally has three basic 
elements. A notation in the distribution portion of secure 
database 610 for each budget record created, the actual budget 
records, and a method option record for inclusion in a 
permissions record. Under some circumstances, a budget process 
may not result in the creation of a method option since an 
existing method option may be being used. Normally, all of this 
output is protected by storage in secure database 610 and/or in 
one or more administrative objects. 



There are two basic modes of operation for a budget 
distribution application in the preferred embodiment. In the first 
case, the operator has an unlimited ability to specify budgets. 
The budgets resulting from this type of activity may be freely 
used to control any aspect of a distribution process for which an 
operator has rights, including for use with "security" budgets 
such as quantities limiting some aspect of usage. For example, if 
the operator is a "regular person," he may use these budgets to 
control his own utilization of objects based on a personal 
accounting model or schedule. If the operator is an authorized 
user at VISA, the resulting budgets may have broad implications 
for an entire distribution system. A core idea is that this mode is 
controlled strictly by an operator. 

The second mode of operation is used to create "alias" 
budgets. These budgets are coupled to a preexisting budget in an 
operator's system. When an operator fills a budget, an 
encumbrance is created on the aliased budget. When these types 
of budgets are created, the output includes two method option 
subrecords coupled together: the method option subrecord for the 
aliased budget, and a method option subrecord for the newly 
created budget. In most cases, the alias budget can be used in 
place of the original budget if the budget creator is authorized to 
modify the method options within the appropriate required 
method record of a permissions record. 
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For example, assume that a user (client administrator) at a 
company has the company's VISA budget on her electronic 
appliance 600. She wants to distribute budget to a network of 
company users with a variety of preexisting budgets and 
requirements. She also wants to limit use of the company's VISA 
budget to certain objects. To do this, she aliases a company 
budget to the VISA budget. She then modifies (if so authorized) 
the permissions record for all objects that the company will allow 
their users to manipulate so that they recognize the company 
budget in addition to, or instead of, the VISA budget. She then 
distributes the new permissions records and budgets to her users. 
The audit data from these users is then reduced against the 
encumbrance on the company's VISA budget to produce a 
periodic billing. 

In another example, a consumer wants to control bis 
family's electronic appliance use of his VISA card, and prevent 
his children from playing too many video games, while allowing 
unlimited use of encyclopedias. In this case, he could create two 
budgets. The first budget can be aliased to his VISA card, and 
might only be used with encyclopedia objects (referenced to 
individual encyclopedia objects and/or to one or more classes of 
encyclopedia objects) that reference the aliased budget in their 
explicitly modified permissions record. The second budget could 
be, for example, a time budget that he redistributes to the family 



for use with video game objects (video game class)* In this 
instance, the second budget is a "self-replenishing 4 * 
security/control budget, that allows, for example, two hours of use 
per day. The first budget operates in the same manner as the 
earlier example* The second budget is added as a new required 
method to permissions records for video games. Since the time 
budget is required to access the video games, an effective control 
path is introduced for requiring the second budget — only 
permissions records modified to accept the family budget can be 
used by the children for video games and they are limited to two 
hours per day. 

Sharing and Distributing Rights and Budgets 
Move 

The VDE "move* concept provided by the preferred 
embodiment covers the case of "friendly sharing" of rights and 
budgets. A typical case of "move" is a user who owns several 
machines and wishes to use the same objects on more than one of 
them. For example, a user owns a desktop and a notebook 
computer. They have a subscription to an electronic newspaper 
that they wish to read on either machine, i.e., the user wishes to 
move rights from one machine to the other. 

An important concept within "move" is the idea of 
independent operation. Any electronic appliance 600 to which 



/ 



»• V ***** — ~ " 

embodiment, this information could be read, directly or 
indirectly, into a computer or electronic organizer money and/or 
tax management program (for example, Quicken or Microsoft 
Money and/or Turbo Tax and/or Andrew Tobias' Managing Your 
Money). This automation of receipt management would be an 
enormous boon to consumers, since the management and 
maintenance of receipts is difficult and time-consuming, receipts 
are often lost or forgotten, and the detail from credit card billings 
is often wholly inadequate for billing and reimbursement 
purposes since credit card billings normally don't provide 
sufficient data on the purchased items or significant transaction 
parameters. 

In one embodiment, the portable appliance 2600 could 
support secure (in this instance encrypted and/or authenticated) 
two-way communications with a retail terminal which may 
contain a VDE electronic appliance 600 or communicate with a 
retailer's or third party provider's VDE electronic appliance 600. 
During such a secure two-way communication between, for 
example, each participant's secure VDE subsystem, portable 
appliance 2600 VDE secure subsystem may provide 
authentication and appropriate credit or debit card information 
to the retail terminal VDE secure subsystem. During the same 
or different communication session, the terminal could similarly, 
securely communicate back to the portable appliance 2600 VDE 



for use with video game objects (video game class). In this 
instance, the second budget is a "self-replenishing* 
security/control budget, that allows, for example, two hours of use 
per day. The first budget operates in the same manner as the 
earlier example. The second budget is added as a new required 
method to permissions records for video games. Since the time 
budget is required to access the video games, an effective control 
path is introduced for requiring the second budget - only 
permissions records modified to accept the family budget can be 
used by the children for video games and they are limited to two 
hours per day. 

Sharing and Distributing Eights and Budgets 
Move 

The VDE "move" concept provided by the preferred 
embodiment covers the case of "friendly sharing" of rights and 
budgets. A typical case of r move" is a user who owns several 
machines and wishes to use the same objects on more than one of 
them. For example, a user owns a desktop and a notebook 
computer. They have a subscription to an electronic newspaper 
that they wish to read on either machine, i.e., the user wishes to 
move rights from one machine to the other. 



An important concept within "move" is the idea of 
independent operation. Any electronic appliance 600 to which 
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rights have been moved may contact distributors or 
clearinghouses independently. For example, the user mentioned 
above may want to take their notebook on the road for an 
extended period of time, and contact clearinghouses and 
distributors without a local connection to their desktop. 

To support independent operation, the user should be able 
to define an account with a distributor or clearinghouse that is 
independent of the electronic appliance 600 she is using to 
connect. The transactions must be independently traceable and 
reconcilable among and between machines for both the end user 
and the clearinghouse or distributor. The basic operations of 
moving rights, budgets, and bitmap or compound meters between 
machines is also supported. 

Redistribution 

Redistribution forms a UDE middle ground between the 
"friendly sharing" of "move," and formal distribution. 
Redistribution can be thought of as "anonymous distribution" in 
the sense that no special interaction is required between a 
creator, clearinghouse, or distributor and a redistributor. Of 
course, a creator or distributor does have the ability to limit or 
prevent redistribution. 



Unlike the "move" concept, redistribution does not imply 
independent operation. The redistribute serves as one point of 
contact for users receiving redistributed rights and/or budgets, 
etc. These users have no knowledge of, or access to, the 
clearinghouse (or and/or distributor) accounts of the 
redistributed The redistributor serves as an auditor for the 
rights and/or budgets, etc. that they redistribute, unless 
specifically overridden by restrictions from distributors and/or 
clearinghouses. Since redistributees (recipients of redistributed 
rights and/or budgets, etc.) would place a relatively 
unquantifiable workload on clearinghouses, and furthermore, 
since a redistributor would be placing himself at an auditable 
risk (responsible for all redistributed rights and/or budgets, etc.), 
the audit of rights, budgets, etc. of redistributees by 
redistributed is assumed as the default case in the preferred 
embodiment. 



Distribution 

Distribution involves three types of entity. Creators 
usually are the source of distribution. They typically set the 
control structure "context" and can control the rights which are 
passed into a distribution network. Distributors are users who 
form a link between object (content) end users and object 
(content) creators. They can provide a two-way conduit for rights 
and audit data. Clearinghouses may provide independent 
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financial services, such as credit and/or billing services, and can 
serve as distributors and/or creators. Through a permissions and 
budgeting process, these parties collectively can establish fine 
control over the type and extent of rights usage and/or auditing 
activities. 

Encumbrance 

An "encumbrance" is a special type of VDE budget. When 
that a budget distribution of any type occurs, an "encumbrance" 
may be generated. An encumbrance is indistinguishable from an 
original budget for right exercise (e.g., content usage payment) 
purposes, but is uniquely identified within distribution records as 
to the amount of the encumbrance, and all necessary information 
to complete a shipping record to track the whereabouts of an 
encumbrance. For right exercise purposes, an encumbrance is 
identical to an original budget; but for tracking purposes, it is 
uniquely identifiable. 

In the preferred embodiment of the present invention, a 
Distribution Event ID will be used by user VDE nodes and by 
clearinghouse services to track and reconcile encumbrances, even 
in the case of asynchronous audits. That is, the "new" 
encumbrance budget is unique from a tracking point of view, but 
indistinguishable from a usage point of view. 



Unresolved encumbrances are a good intermediate control 
for a VDE distribution process. A suitable ''grace period" can be 
introduced during which encumbrances must be resolved. If this 
period elapses, an actual billing or payment may occur. However, 
even after the interval has expired and the billing and/or 
payment made, an encumbrance may still be outstanding and 
support later reconciliation. In this case, an auditor may allow a 
user to gain a credit, or a user may connect to a VDE node 
containing an encumbered budget, and resolve an amount as an 
internal credit. In some cases, missing audit trails may concern a 
distributor sufficiently to revoke redistribution privileges if 
encumbrances are not resolved within a "grace period, 4 " or if there 
are repeated grace period violations or if unresolved 
encumbrances are excessively large. 

Encumbrances can be used across a wide variety of 
distribution modes. Encumbrances, when used in concert with 
aliasing of budgets, opens important additional distribution 
possibilities. In the case of aliasing a budget, the user places 
himself in the control path for an object - an aliased budget may 
only be used in conjunction with permissions records that have 
been modified to recognize it. An encumbrance has no such 
restrictions. 
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For example, a user may want to restrict his children's use 
ofhis electronic, VDE node VISA budget. In this case, the user 
can generate an encumbrance on his VISA budget for the 
children's family alias budget, and another for his wife that is a 
transparent encumbrance of the original VISA budget. BigCo 
may use a similar mechanism to distribute VISA budget to 
department heads, and aliased BigCo budget to users directly. 

Account Numbers and User IDs 

In the preferred embodiment, to control access to 
clearinghouses, users are assigned account numbers at 
clearinghouses. Account numbers provide a unique "instance 4 ' 
value for a secure database record from the point of view of an 
outsider. From the point of view of an electronic appliance 600 
site, the user, group, or group/user ids provide the unique 
instance of a record. For example, from the point of view of VISA, 
your Gold Card belongs to account number #123456789. From 
the point of view of the electronic appliance site (for example, a 
server at a corporation), the Gold card might belong to user id 
1023. In organizations which have plural users and/or user 
groups using a VDE node, such users and/or user groups will 
likely be assigned unique user IDs. differing budgets and/or 
other user rights may be assigned to different users and/or user 
groups and/or other VDE control information may be applied on a 
differing manner to electronic content and/or appliance usage by 



users assigned with different such IDs. Of course, both a 
clearinghouse and a local site will likely have both pieces of 
information, but "used data" versus the "comment data" may 
differ based on perspective. 

In the preferred embodiment case of "move," an account 
number stored with rights stays the same. In the preferred 
embodiment of other forms of distribution, a new account number 
is required for a distributee. This may be generated 
automatically by the system, or correspond to a methodology 
developed by a distributor or redistributor. Distributors 
maintain account numbers (and associated access secrets) in 
their local name services for each distributee. Conversely, 
distributees , name services may store account numbers based on 
user id for each distributor. This record usually is moved with 
other records in the case of move, or is generated during other 
forms of distribution. 

Organizations (including families) may automatically 
assign unique user IDs when creating control information (e.g., a 
budget) for a new user or user group. 

Requirements Record 

In order to establish the requirements, and potentially 
options, for exercising a right associated with a VDE content 
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container object before one or more required permissions records 
are received for that object, a requirements record may exist in 
the private header of such an object. This record will help the 
user establish what they have, and what they need from a 
distributor prior to forming a connection. If the requirements or 
possibilities for exercising a particular right have changed since 
such an object was published, a modified requirements record 
may be included in a container with an object (if available and 
allowed), or a new requirements record may be requested from a 
distributor before registration is initiated. Distributors may 
maintain "catalogs" online, and/or delivered to users, of 
collections of requirements records and/or descriptive information 
corresponding to objects for which they may have ability to obtain 
and/or grant rights to other users. 

Passing an Audit 

In the preferred embodiment ofVDE there may be at least 
two types of auditing. In the case of budget distribution, billing 
records that reflect consumption of a budget generally need to be 
collected and processed. In the case of permissions distribution, 
usage data associated with an object are also frequently required. 



In order to effect control over an object, a creator may 
establish the basic control information associated with an object. 



This is done in the formulation of permissions, the distribution of 
various security, administrative and/or financial budgets, and the 
level of redistribution that is allowed, etc. Distributors (and 
redistributors) may further control this process within the rights, 
budgets, etc. (senior control information) they have received. 

For example, an object creator may specify that additional 
required methods may be added freely to their permissions 
records, establish no budget for this activity, and allow unlimited 
redistribution of this right. As an alternative example, a creator 
may allow moving of usage rights by a distributor to half a dozen 
subdistributors, each of whom can distribute 10,000 copies, but 
with no redistribution rights being allowed to be allocated to 
subdistributors' (redistributors') customers. As another example, 
a creator may authorize the moving of usage rights to only 10 
VDE nodes, and to only one level of distribution (no 
redistribution). Content providers and other contributors of 
control information have the ability through the use of 
permissions records and/or component assemblies to control 
rights other users are authorized to delegate in the permissions 
records they send to those users, so long as such right to control 
one, some, or all such rights of other users is either permitted or 
restricted (depending on the control information distribution 
model). It is possible and often desirable, using VDE, to 
construct a mixed model in which a distributor is restricted from 
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controlling certain rights of subsequent users and is allowed to 
control other rights. VDE control of rights distribution in some 
VDE models will in part or whole, at least for certain one or more 
"levels" of a distribution chain, be controlled by electronic content 
control information providers who are either not also providers of 
the related content or provide only a portion of the content 
controlled by said content control information, for example, in 
certain models, a clearinghouse might also serve as a rights 
distribution agent who provides one or more rights to certain 
value chain participants, which one or more rights may be 
"attached" to one or more rights to use the clearinghouse's credit 
(if said clearinghouse is, at least in part, a financial 
clearinghouse (such a control information provider may 
alternatively, or in addition, restrict other users' rights. 

A content creator or other content control information 
provider may budget a user (such as a distributor) to create an 
unlimited number of permissions records for a content object, but 
revoke this right and/or other important usage rights through an 
expiration/termination process if the user does not report his 
usage (provide an audit report) at some expected one or more 
points in time and/or after a certain interval of time (and/or if the 
user fails to pay for his usage or violates other aspects of the 
agreement between the user and the content provider). This 
termination (or suspension or other specified consequence) can be 



enforced, for example, by the expiration of time-aged encryption 
keys which were employed to encrypt one or more aspects of 
control information. This same termination (or other specified 
consequence such as budget reduction, price increase, message 
displays on screen to users, messages to administrators, etc.) can 
also be the consequence of the failure by a user or the users VDE 
installation to complete a monitored process, such as paying for 
usage in electronic currency, failure to perform backups of 
important stored information (e.g., content and/or appliance 
usage information, control information, etc.), failure to use a 
repeated failure to use the proper passwords or other identifiers, 
etc.). 

Generally, the collection of audit information that is 
collected for reporting to a certain auditor can be enforced by 
expiration and/or other termination processes. For example, the 
user's VDE node may be instructed (a) from an external source to 
no longer perform certain tasks, (b) carries within its control 
structure information informing it to no longer perform certain 
tasks, or (c) is elsewise no longer able to perform certain tasks. 
The certain tasks might comprise one or more enabling 
operations due to a user's (or installation's) failure to either 
report said audit information to said auditor and/or receive back 
a secure confirmation of receipt and/or acceptance of said audit 
information. If an auditor fails to receive audit information from 



a user (or some other event fails to occur or occur properly), one 
or more time-aged keys which are used, for example, as a security 
component of an embodiment of the present invention, may have 
their aging suddenly accelerated (completed) so that one or more 
processes related to said time-aged keys can no longer be 
performed. 

Authorization Access Tags and Modification Access Tags 

In order to enable a user VDE installation to pass audit 
information to a VDE auditing party such as a Clearinghouse, 
VDE allows a VDE auditing party to securely, electronically 
communicate with the user VDE installation and to query said 
installation for certain or all information stored within said 
installation's secure sub-system, depending on said auditing 
party's rights (said party shall normally be unable to access 
securely stored information that said party is not expressly 
authorized to access, that is one content provider will normally 
not be authorized to access content usage information related to 
content provided by a different content provider). The auditing 
party asserts a secure secret (e.g., a secure tag) that represents 
the set of rights of the auditor to access certain information 
maintained by said subsystem. If said subsystem validates said 
tag, the auditing party may then receive auditing information 
. that it is allowed to request and receive. 



Great flexibility exists in the enforcement of audit trail 
requirements. For example, a creator (or other content provider 
or control information provider or auditor in an object's or audit 
report's chain of handling) may allow changes by an auditor for 
event trails, but not allow anyone but themselves to read those 
trails, and limit the redistribution of this right to, for example, six 
levels. Alternatively, a creator or other controlling party may 
give a distributor the right to process, for example, 100,000 audit 
records (and/or, for example, the right to process 12 audit records 
from a given user) before reporting their usage. If a creator or 
other controlling party desires, he may allow (and/or require) 
separate (and containing different, a subset of, overlapping, or 
the same information) audit "packets" containing audit 
information, certain of said audit information to be processed by 
a distributor and certain other of said audit information to be 
passed back to the creator and/or other auditors (each receiving 
the same, overlapping, a subset of, or different audit 
information). Similarly, as long as allowed by, for example, an 
object creator, a distributor (or other content and/or control 
information provider) may require audit information to be passed 
back to it, for example, after every 50,000 audit records are 
processed (or any other unit of quantity and/or after a certain 
time interval and/or at a certain predetermined date) by a 
redistributor. In the preferred embodiment, audit rules, like 
other control structures, may be stipulated at any stage of a 
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distribution chain of handling as long as the right to stipulate 
said rules has not been restricted by a more "senior" object and/or 
control information distributing (such as an auditing) 
participant. 

Audit information that is destined for different auditors 
may be encrypted by different one or more encryption keys which 
have been securely provided by each auditor's VDE node and 
communicated for inclusion in a user's permissions record(s) as a 
required step, for example, during object registration. This can 
provide additional security to further ensure (beyond the use of 
passwords and/or other identification information and other VDE 
security features) that an auditor may only access audit 
information to which he is authorized. In one embodiment, 
encrypted (and/or unencrypted) "packets" of audit information 
(for example, in the form of adininistrative objects) may be bound 
for different auditors including a clearinghouse and/or content 
providers and/or other audit information users (including, for 
example, market analysts and/or list purveyors). The 
information may pass successively through a single chain of 
handling, for example, user to clearinghouse to redistributor to 
distributor to publisher/object creator, as specified by VDE audit 
control structures and parameters. Alternatively, encrypted (or, 
normally less preferably, unencrypted) audit packets may be 
required to be dispersed directly from a user to a plurality of 



auditors, some one or more who may have the responsibility to 
"pass along 4 " audit packets to other auditors. In another 
embodiment, audit information may be passed, for example, to a 
clearinghouse, which may then redistribute all and/or 
appropriate subsets of said information (and/or some processed 
result) to one or more other parties, said redistribution employing 
VDE secure objects created by said clearinghouse. 

An important function of an auditor (receiver of audit 
information) is to pass administrative events back to a user VDE 
node in acknowledgement that audit information has been 
received and/or "recognized." In the preferred embodiment, the 
receipt and/or acceptance of audit information may be followed by 
two processes. The first event will cause the audit data at a VDE 
node which prepared an audit report to be deleted, or compressed 
into, or added to, one or more summary values. The second 
event, or set of events, will "inform" the relevant security (for 
example, termination and/or other consequence) control 
information (for example, budgets) at said VDE node of the audit 
receipt, modify expiration dates, provide key updates, and/or etc. 
In most cases, these events will be sent immediately to a site 
after an audit trail is received. In some cases, this transmission 
may be delayed to, for example, first allow processing of the audit 
trail and/or payment by a user to an auditor or other party. 



In the preferred embodiment, the administrative events for 
content objects and independently distributed 
methods/component assemblies are similar, but not necessarily 
identical. For example, key updates for a budget may control 
encryption of a billing trail, rather than decryption of object 
content. The billing trail for a budget is in all respects a method 
event trail. In one embodiment, this trail must include sufficient 
references into distribution records for encumbrances to allow 
reconciliation by a clearinghouse. This may occur, for example, if 
a grace period elapses and the creator of a budget allows 
unresolved encumbrances to ultimately yield automatic credits if 
an expired encumbrance is "returned" to the creator. 

Delivery of audit reports through a path of handling may 
be in part insured by an inverse (return of information) audit 
method. Many VDE methods have at least two pieces: a portion 
that manages the process of producing audit information at a 
user's VDE node; and a portion that subsequently acts on audit 
data. In an example of the handling of audit information bound 
for a plurality of auditors, a single container object is received at 
a clearinghouse (or other auditor). This container may contain 
(a) certain encrypted audit information that is for the use of the 
clearinghouse itself, and (b) certain other encrypted audit 
information bound for other one or more auditor parties. The two 
sets of information may have the same, overlapping and in part 
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different, or entirely different, information content. 
Alternatively, the clearinghouse VDE node may be able to work 
with some or all of the provided audit information. The audit 
information may be, in part, or whole, in some summary and/or 
analyzed form further processed at the clearinghouse and/or may 
be combined with other information to form a, at least in part, 
derived set of information and inserted into one or more at least 
in part secure VDE objects to be communicated to said one or 
more (further) auditor parties. When an audit information 
container is securely processed at said clearinghouse VDE node 
by said inverse (return) audit method, the clearinghouse VDE 
node can create one or more VDE administrative objects for 
securely carrying audit information to other auditors while 
separately processing the secure audit information that is 
specified for use by said clearinghouse. Secure audit processes 
and credit information distribution between VDE participants 
normally takes place within the secure VDE "black box," that is 
processes are securely processed within secure VDE PPE650 and 
audit information is securely communicated between the VDE 
secure subsystems of vDE participants employing VDE secure 
communication techniques (e.g., public key encryption, and 
authentication). 

This type of inverse audit method may specify the handling 
of returned audit information, including, for example, the local 



processing of audit information and/or the secure passing along of 
audit information to one or more auditor parties. If audit 
information is not passed to one or more other auditor parties as 
may be required and according to criteria that may have been set 
by said one or more other auditor parties and/or content 
providers and/or control information providers during a 
permissions record specification and/or modification process, the 
failure to, for example, receive notification of successful transfer 
of required audit information by an auditor party, e.g., a content 
provider, can result in the disablement of at least some capability 
of the passing through party's VDE node (for example, 
disablement of the ability to further perform certain one or more 
VDE managed business functions that are related to object(s) 
associated with said audit or party). In this preferred 
embodiment example, when an object is received by an auditor, it 
is automatically registered and permissions record(s) contents 
are entered into the secure management database of the auditor's 
VDE node. 

One or more permissions records that manage the creation 
and use of an audit report object (and may manage other aspects 
of object use as well) may be received by a user's system during 
an audit information reporting exchange (or other electronic 
interaction between a user and an auditor or auditor agent). 
Each received permissions record may govern the creation of the 



WO 96/27155 



next audit report object. After the reporting of audit information, 
a new permissions record may be required at a user's VDE node 
to refresh the capability of managing audit report creation and 
audit information transfer for the next audit reporting cycle. In 
our above example, enabling an auditor to supply one or more 
permissions records to a user for the purpose of audit reporting 
may require that an auditor (such as a clearinghouse) has 
received certain, specified permissions records itself from 
"upstream" auditors (such as, for example, content and/or other 
content control information providers). Information provided by 
these upstream permissions records may be integrated into the 
one or more permissions records at an auditor VDE (e.g., 
clearinghouse) installation that manage the permissions record 
creation cycle for producing administrative objects containing 
permissions records that are bound for users during the audit 
information reporting exchange. If an upstream auditor fails to 
receive, and/or is unable to process, required audit information, 
this upstream auditor may fail to provide to the clearinghouse (in 
this example) the required permissions record information which 
enables a distributor to support the next permission record 
creation/auditing cycle for a given one or more objects (or class of 
objects). As a result, the clearinghouse's VDE node may be 
unable to produce the next cycle's permissions records for users, 
and/or perform some other important process. This VDE audit 
reporting control process may be entirely electronic process 



management involving event driven VDE activities at both the 
intended audit information receiver and sender and employing 
both their secure PPE650 and secure VDE communication 
techniques. 

In the preferred embodiment, each time a user registers a 
new object with her own VDE node, and/or alternatively, with a 
remote clearinghouse and/or distributor VDE node, one or more 
permissions records are provided to, at least in part, govern the 
use of said object. The permissions records may be provided 
dynamically during a secure UDE registration process 
(employing the VDE installation secure subsystem), and/or may 
be provided following an initial registration and received at some 
subsequent time, e.g. through one or more separate secure VDE 
communications, including, for example, the receipt of a physical 
arrangement containing or otherwise carrying said information. 
At least one process related to the providing of the one or more 
permissions records to a user can trigger a metering event which 
results in audit information being created reflecting the user's 
VDE node's, clearinghouse's, and/or distributor's permissions 
records provision process. This metering process may not only 
record that one or more permissions records have been created. 
It may also record the VDE node name, user name, associated 
object identification information, time, date, and/or other 
identification information. Some or all of this information can 



become part of audit information securely reported by a 
clearinghouse or distributor, for example, to an auditing content 
creator and/or other content provider. This information can be 
reconciled by secure VDE applications software at a receiving 
auditor's site against a user's audit information passed through 
by said clearinghouse or distributor to said auditor. For each 
metered one or more permissions records (or set of records) that 
were created for a certain user (and/or VDE node) to manage use 
of certain one or more VDE object(s) and/or to manage the 
creation of VDE object audit reports, it may be desirable that an 
auditor receive corresponding audit information incorporated into 
an, at least in part, encrypted audit report. This combination of 
metering of the creation of permissions records; secure, encrypted 
audit information reporting processes; secure VDE subsystem 
reconciliation of metering information reflecting the creation of 
registration and/or audit reporting permissions with received 
audit report detail; and one or more secure VDE installation 
expiration and/or other termination and/or other consequence 
processes; taken together significantly enhances the integrity of 
the VDE secure audit reporting process as a trusted, efficient, 
commercial environment. 
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Secure Document Management Example 

VDE 100 may be used to implement a secure document 
management environment. The following are some examples of 
how this can be accomplished. 

In one example, suppose a law firm wants to use VDE 100 
to manage documents. In this example, a law firm that is part of 
a litigation team might use VDE in the following ways: 

1. to securely control access to, and/or other usage of, 
confidential client records, 

2. to securely control access, distribution, and/or other 
rights to documents and memoranda created at the 
law firm, 

3. to securely control access and other use of research 
materials associated with the case, 

4. to securely control access and other use, including 
distribution of records, documents, and notes 
associated with the case, 

5. to securely control how other firms in the litigation 
team may use, including change, briefs that have 
been distributed for comment and review, 

6. to help manage client billing. 
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The law firm may also use VDE to electronically file briefs with 
the court (presuming the court is also VDE capable) including 
providing secure audit verification of the ID (e.g., digital 
signature) of filers and other information pertinent to said filing 
procedure. 

In this example, the law firm receives in VDE content 
containers documents from their client's VDE installation secure 
subsystem(s). Alternatively, or in addition, the law firm may 
receive either physical documents which may be scanned into 
electronic form, and/or they receive electronic documents which 
have not yet been placed in VDE containers. The electronic form 
of a document is stored as a VDE container (object) associated 
with the specific client and/or case. The VDE container 
mechanism supports a hierarchical ordering scheme for 
organizing files and other information within a container; this 
mechanism may be used to organize the electronic copies of the 
documents within a container, A VDE container is associated 
with specific access control information and rights that are 
described in one or more permissions control information sets 
(PERCsj associated with that container. In this example, only 
those members of the law firm who possess a VDE instance, an 
appropriate PERC, and the VDE object that contains the desired 
document, may use the document. Alternatively or in addition, a 
law firm member may use a VDE instance which has been 
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installed on the law firm's network server. In this case, the 
member must be identified by an appropriate PERC and have 
access to the document containing VDE object (in order to use the 
server VDE installation). Basic access control to electronic 
documents is enabled using the secure subsystem of one or more 
user VDE installations. 



VDE may be used to provide basic usage control in several 
ways. First, it permits the "embedding" of multiple containers 
within a single object. Embedded objects permit the "nesting" of 
control structures within a container. VDE also extends usage 
control information to an arbitrary granular level (as opposed to 
a file based level provided by traditional operating systems) and 
provides flexible control information over any action associated 
with the information which can be described as a VDE controlled 
process. For example, simple control information may be 
associated with viewing the one or more portions of documents 
and additional control information may be associated with 
editing, printing and copying the same and/or different one or 
more portions of these same documents. 

In this example, a "client" container contains all documents 
that have been provided by the client (documents received in 
other containers can be securely extracted and embedded into the 
VDE client container using VDE extraction and embedding 



capabilities). Each document in this example is stored as an 
object within the parent, client VDE container. The "client" 
container also has several other objects embedded within it; one 
for each attorney to store their client notes, one (or more) for 
research results and related information, and at least one for 
copies of letters, work papers, and briefs that have been created 
by the law firm. The client container may also contain other 
information about the client, including electronic records of 
billing, time, accounting, and payments. Embedding VDE objects 
within a parent VDE content container provides a convenient 
way to securely categorize and/or store different information that 
shares similar control information. All client provided documents 
may, for example, be subject to the same control structures 
related to use and non-disclosure. Attorney notes may be subject 
to control information, for example, their use may be limited to 
the attorney who created the notes and those attorneys to whom 
such creating attorney expressly grants access rights. Embedded 
containers also provide a convenient mechanism to control 
collections of dissimilar information. For example, the research 
object(s) may be stored in the form of (or were derived from) VDE 
"smart objects'' that contain the results of research performed by 
that object. Research results related to one aspect of the case 
retrieved from a VDE enabled LEXIS site might be encapsulated 
as one smart object; the results of another session related to 
another (or the same) aspect of the case may be encapsulated as a 



different object. Smart objects are used in tins example to help 
show that completely disparate and separately delivered control 
information may be incorporated into a client container as 
desired and/or required to enforce the rights of providers (such as 
content owners). 

Control structures may be employed to manage any variety 
of desired granularities and/or logical document content 
groupings; a document, page, paragraph, topically related 
materials, etc. In this example, the following assumptions are 
made: client provided documents are controlled at the page level, 
attorney notes are controlled at the document level on an 
attorney by attorney basis, court filings and briefs are controDed 
at a document level, research information is controlled at 
whatever level the content provider specifies at the time the 
research was performed, and certain highly confidential 
information located in various of the above content may be 
identified as subject to display and adding comments only, and 
only by the lead partner attorneys, with only the creator and/or 
embedder of a given piece of content having the right to be 
otherwise used (printed, extracted, distributed, etc). 



In general, container content in this example is controlled 
with respect to distribution of rights. This control information 
are associated at a document level for all internally generated 



documents, at a page level for client level documents, and at the 
level specified by the content provider for research documents. 

VDE control information can be structured in either 
complex or simple structures, depending on the participant's 
desires. In some cases, a VDE creator will apply a series of 
control structure definitions that they prefer to use (and that are 
supported by the VDE application managing the specification of 
rules and control information, either directly, or through the use 
of certified application compatible VDE component assemblies. 

In this example, the law firm sets up a standard VDE 
client content container for a new client at the time they accept 
the case. A law firm VDE administrator would establish a VDE 
group for the new client and add the VDE IDs of the attorneys at 
the firm that are authorized to work on the case, as well as 
provide, if appropriate, one or more user template applications. 
These templates provide, for example, one or more user interfaces 
and associated control structures for selection by users of 
additional and/or alternative control functions (if allowed by 
senior control information), entry of control parameter data, 
and/or performing user specific administrative tasks. The 
administrator uses a creation tool along with a predefined 
creation template to create the container. This creation template 
specifies the document usage (including distribution control 



information) for documents as described above. Each electronic 
document from the client (including letters, memoranda, E-mail, 
spreadsheet, etc.) are then added to the container as separate 
embedded objects. Each new object is created using a creation 
template that satisfies that the default control structures 
specified with the container as required for each new object of a 
given type. 

As each attorney works on the case, they may enter notes 
into an object stored within the client's VDE container. These 
notes may be taken using a VDE aware word processor already in 
use at the law firm. In this example, a VDE redirector handles 
the secure mapping of the word processor file requests into the 
VDE container and its objects through the use of VDE control 
processes operating with one or more VDE PPEs. Attorney note 
objects are created using the default creation template for the 
document type with assistance from the attorney if the type 
cannot be automatically determined from the content. This 
permits VDE to automatically detect and protect the notes at the 
predetermined level, e.g. document, page, paragraph. 

Research can be automatically managed using VDE. 
Smart objects can be, used to securely search out, pay for if 
necessary, and retrieve information from VDE enabled 
information resources on the information highway. 
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Examples of such resources might include LEXIS, 
Westlaw, and other related legal databases. Once the 
information is retrieved, it may be securely embedded in the VDE 
content client container. If the smart object still contains 
unreleased information, the entire smart object may be 
embedded in the client's VDE container. This places the 
unreleased information under double VDE control requirements: 
those associated with releasing the information from smart object 
(such as payment and/or auditing requirements) and those 
associated with access to, or other usage of, client information of 
the specified type. 



Briefs and other filings may be controlled in a manner 
similar to that for attorney notes. The filings may be edited 
using the standard word processors in the law firm; with usage 
control structures controlling who may review, change, and/or 
add to the document (or, in a more sophisticated example, a 
certain portion of said document). VDE may also support 
electronic filing of briefs by providing a trusted source for 
time/date stamping and validation of filed documents. 

When the client and attorney want to exchange 
confidential information over electronic mail or other means, 
VDE can play an important role in ensuring that information 
exchanged under privilege, properly controlled, and not 
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inappropriately released and/or otherwise used. The materials 
(content) stored in a VDE content container object will normally 
be encrypted. Thus wrapped, a VDE object may be distributed to 
the recipient without fear of unauthorized access and/or other 
use. The one or more authorized users who have received an 
object are the only parties who may open that object and view 
and/or manipulate and/or otherwise modify its contents and VDE 
secure auditing ensures a record of all such user content 
activities. VDE also permits the revocation of rights to use 
client/attorney privileged information if such action becomes 
necessary, for example, after an administrator review of user 
usage audit information. 

Large Organization Example 

In a somewhat more general example, suppose an 
organization (e.g., a corporation or government department) with 
thousands of employees and numerous offices disposed 
throughout a large geographic area wishes to exercise control 
over distribution of information which belongs to said 
organization (or association). This information may take the 
form of formal documents, electronic mail messages, text files, 
multimedia files, etc,, which collectively are referred to as 
"documents." 
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Such documents may be handled by people (referred to as 
"users") and/or by computers operating on behalf of users. The 
documents may exist both in electronic form for storage and 
transmission and in paper form for manual handling. 

These documents may originate whoDy within the 
organization, or may be created, in whole or in part, from 
information received from outside the organization. Authorized 
persons within the organization may choose to release 
documents, in whole or in part, to entities outside the 
organization. Some such entities may also employ VDE 100 for 
document control, whereas others may not. 

Document Control Policies 

The organization as a whole may have a well-defined policy 
for access control to, and/or other usage control of documents. 
This policy may be based on a "lattice model" of information flow, 
in which documents are characterized as having one or more 
hierarchical "classification* security attributes 9903 and zero or 
more non-hierarchical "compartment" security attributes, all of 
which together comprise a sensitivity security attribute. 

The classification attributes may designate the overall 
level of sensitivity of the document as an element of an ordered 
set. For example, the set "unclassified" "confidential," "secret," 



"top secret" might be appropriate in a government setting, and 
the set "public," "internal,* "confidential" "registered 
confidential" might be appropriate in a corporate setting. 

The compartment attributes may designate the document's 
association with one or more specific activities within the 
organization, such as departmental subdivisions (e.g., "research," 
"development," "marketing") or specific projects within the 
organization. 

Each person using an electronic appliance 600 would be 
assigned, by an authorized user, a set of permitted sensitivity 
attributes to designate those documents, or one or more portions 
of certain document types, which could be processed in certain 
one or more ways, by the person's electronic appliance. A 
document's sensitivity attribute would have to belong to the 
user's set of permitted sensitivity values to be accessible. 

In addition, the organization may desire to permit users to 
exercise control over specific documents for which the user has 
some defined responsibility. As an example, a user (the 
"originating user") may wish to place an "originator controlled" 
("ORCON") restriction on a certain document, such that the 
document may be transmitted and used only by those specific 
other users whom he designates land only in certain, expressly 



authorized ways). Such a restriction may be flexible if the 
"distribution list" could be modified after the creation of the 
document, specifically in the event of someone requesting 
permission from the originating user to transmit the document 
outside the original list of authorized recipients. The originating 
user may wish to permit distribution only to specific users, 
defined groups of users, defined geographic areas, users 
authorized to act in specific organizational roles, or a combination 
of any or all such attributes. 

In this example, the organization may also desire to permit 
users to define a weaker distribution restriction such that access 
to a document is limited as above, but certain or all information 
within the document may be extracted and redistributed without 
further restriction by the recipients. 

The organization and/or originating users may wish to 
know to what uses or geographic locations a document has been 
distributed. The organization may wish to know where 
documents with certain protection attributes have been 
distributed, for example, based on geographic information stored 
in site configuration records and/or name services records. 

A user may wish to request a "return receipt" for a 
distributed document, or may wish to receive some indication of 
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how a document has been handled by its recipients (e.g., whether 
it has been viewed, printed, edited and/or stored), for example, by 
specifying one or more audit requirements (or methods known to 
have audit requirements) in a PERC associated with such 
documents). 

User Environment 

In an organization (or associateion) such as that described 
above, users may utilize a variety of electronic appliances 600 for 
processing and managing documents. This may include personal 
computers, both networked and otherwise, powerful single-user 
workstations, and servers or mainframe computers. To provide 
support for the control information described in this example, 
each electronic appliance that participates in use and 
management of VDE-protected documents may be enhanced with 
a VDE secure subsystem supporting an SPE 503 and/or HPE 
655. 

In some organizations, where the threats to secure 
operation are relatively low, an HPE 655 may suffice. In other 
organizations (e.g., government defense), it may be necessary to 
employ an SPE 503 in all situations where VDE-protected 
documents are processed. The choice of enhancement 
environment and technology may be different in different of the 
organization. Even if different types of PPE 650 are used within 



an organization to serve different requirements, they may be 
compatible and may operate on the same types (or subsets of 
types) of documents* 

Users may employ application programs that are 
customized to operate in cooperation with the VDE for handling 
of VDE-protected documents. Examples of this may include 
VDE-aware document viewers, VDE aware electronic mail 
systems, and similar applications. Those programs may 
communicate with the PPE 650 component of a user's electronic 
appliance 600 to make VDE-protected documents available for 
use while limiting the extent to which their contents may be 
copied, stored, viewed, modified, and/or transmitted and/or 
otherwise further distributed outside the specific electronic 
appliance. 

Users may wish to employ commercial, off-the-shelf 
("COTS") operating systems and application programs to process 
the VDE-protected documents. One approach to permit the use 
of COTS application programs and operating systems would be to 
allow such use only for documents without restrictions on 
redistribution. The standard VDE operating system redirector 
would allow users to access VDE-protected documents in a 
manner equivalent to that for files. In such an approach, 
however, a chain of control for metering and/or auditing use may 
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be "broken" to some extent at the point that the protected object 
was made available to the COTS application. The fingerprinting 
(watermarking) techniques ofVDE may be used to facilitate 
further tracking of any released information. 

A variety of techniques may be used to protect printing of 
protected documents, such as, for example: server-based 
decryption engines, special fonts for "fingerprinting," etc. 

Another approach to supporting COTS software would use 
the VDE software running on the user's electronic appliance to 
create one or more "virtual machine'' environments in which 
COTS operating system and application programs may run, but 
from which no information may be permanently stored or 
otherwise transmitted except under control of VDE. Such an 
environment would permit VDE to manage all VDE-protected 
information, yet may permit unlimited use of COTS applications 
to process that information within the confines of a restricted 
environment. The entire contents of such an environment could 
be treated by VDE 100 as an extension to any VDE-protected 
documents read into the environment. Transmission of 
information out of the environment could be governed by the 
same rules as the original documents). 



'Coarse-Grain* Control Capabilities 

As mentioned above, an organization may employ 
VDE-enforced control capabilities to manage the security, 
distribution, integrity, and control of entire documents. Some 
examples of these capabilities may include: 

1) A communication channel connecting two or more 
electronic appliances 600 may be assigned a set of 
permitted sensitivity attributes. Only documents 
whose sensitivity attributes belong to this set would 
be permitted to be transmitted over the channel. 
This could be used to support the Device Labels 
requirement of the Trusted Computer System 
Evaluation Criteria (TCSEC). 

2) A writable storage device (e.g., fixed disk, diskette, 
tape drive, optical disk) connected to or incorporated 
in an electronic appliance 600 may be assigned a set 
of permitted sensitivity attributes. Only documents 
whose sensitivity attributes belong to this set would 
be permitted to be stored on the device. This could 
be used to support the TCSEC Device Labels 
requirement. 



A document may have a list of users associated with 
it representing the users who are permitted to 
"handle* the document. This list of users may 
represent, for example, the only users who may view 
the document, even if other users receive the 
document container, they could not manipulate the 
contents. This could be used to support the standard 
ORCON handling caveat. 

A document may have an attribute designating its 
originator and requiring an explicit permission to be 
granted by an originator before the document's 
content could be viewed. This request for permission 
may be made at the time the document is accessed 
by a user, or, for example, at the time one user 
distributes the document to another user. If 
permission is not granted, the document could not be 
manipulated or otherwise used. 

A document may have an attribute requiring that 
each use of the document be reported to the 
document's originator. This may be used by an 
originator to gauge the distribution of the document. 
Optionally, the report may be required to have been 
made successfully before any use of the document is 



Tf\f TWA/139 



permitted, to ensure that the use is known to the 
controlling party at the time of use. Alternatively, 
for example, the report could be made in a deferred 
("batch") fashion. 

6) A document may have an attribute requiring that 
each use of the document be reported to a central 
document tracking clearinghouse. This could be 
used by the organization to track specific documents, 
to identify documents used by any particular user 
and/or group of users to track documents with 
specific attributes (e.g., sensitivity), etc. Optionally, 
for example, the report may be required to have been 
made successfully before any use of the document is 
permitted. 

7) A VDE protected document may have an attribute 
requiring that each use of the document generate a 
"return receipt," to an originator. A person using the 
document may be required to answer specific 
questions in order to generate a return receipt, for 
example by indicating why the document is of 
interest, or by indicating some knowledge of the 
document's contents (after reading it). This may be 
used as assurance that the document had been 



handled by a person, not by any automated software 
mechanism. 

A VDE protected document's content may be made 
available to a VDE-unaware application program in 
such a way that it is uniquely identifiable (traceable) 
to a user who caused its release. Thus, if the 
released form of the document is further distributed, 
its origin could be determined. This may be done by 
employing VDE "fingerprinting* for content release. 
Similarly, a printed VDE protected document may 
be marked in a similar, VDE fingerprinted unique 
way such that the person who originally printed the 
document could be determined, even if copies have 
since been made. 

Usage of VDE protected documents could be 
permitted under control of budgets that limit (based 
on size, time of access, etc.) access or other usage of 
document content. This may help prevent wholesale 
disclosure by limiting the number of VDE documents 
accessible to an individual during a fixed time 
period. For example, one such control might permit 
a user, for some particular class of documents, to 
view at most 100 pages/day, but only print 10 



pages/day and permit printing only on weekdays 
between nine and five. As a further example, a user 
might be restricted to only a certain quantity of 
logically related, relatively "contiguous" and/or some 
other pattern (such as limiting the use of a 
database's records based upon the quantity of 
records that share a certain identifier in field) of 
VDE protected document usage to identify, for 
example, the occurrence of one or more types of 
excessive database usage (under normal or any 
reasonable circumstances). As a result, VDE content 
providers can restrict usage of VDE content to 
acceptable usage characteristics and thwart and/or 
identify (for example, by generating an exception 
report for a VDE administrator or organization 
supervisor) user attempts to inappropriately use, for 
example, such an information database resource. 

These control capabilities show some examples of how VDE 
can be used to provide a flexible, interactive environment for 
tracking and managing sensitive documents. Such an 
environment could directly trace the flow of a document from 
person to person, by physical locations, by organizations, etc. It 
would also permit specific questions to be answered such as 
"what persons outside the R&D department have received any 
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R&D-controlled document" Because the control information is 
carried with each copy of a VDE protected document, and can 
ensure that central registries are updated and/or that originators 
are notified of document use, tracking can be prompt and 
accurate. 

This contrasts with traditional means of tracking paper 
documents: typically, a paper-oriented system of manually 
collected and handled receipts is used. Documents may be 
individually copy-numbered and signed for, but once distributed 
are not actively controlled. In a traditional paper-oriented 
system, it is virtually impossible to determine the real locations 
of documents; what control can be asserted is possible only if all 
parties strictly follow the handling rules (which are at best 
inconvenient). 



The situation is no better for processing documents within 
the context of ordinary computer and network systems. Although 
said systems can enforce access control information based on user 
identity, and can provide auditing mechanisms for tracking 
accesses to files, these are low-level mechanisms that do not 
permit tracking or controlling the flow of content. In such 
systems, because document content can be freely copied and 
manipulated, it is not possible to determine where document 
content has gone, or where it came from. In addition, because the 





control mechanisms in ordinary computer operating systems 
operate at a low level of abstraction, the entities they control are 
not necessarily the same as those that are manipulated by users. 
This particularly causes audit trails to be cluttered with 
voluminous information describing uninteresting activities. 

Fine-Grain" Control Capabilities 

In addition to controlling and managing entire documents, 
users may employ customized VDE-aware application software to 
control and manage individual modifications to documents. 
Examples of these capabilities include the following: 

1) A VDE content user may be permitted to append 
further information to a VDE document to indicate a 
proposed alternative wording. This proposed 
alteration would be visible to all other users (in 
addition to the original text) of the document but 
would (for example) be able to be incorporated into 
the actual text only by the document's owner. 

2) A group of VDE users could be permitted to modify 
one or more parts of a document in such a way that 
each individual alteration would be unambiguously 
traceable to the specific user who performed it. The 
rights to modify certain portions of a document, and 
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the extension of differing sets of rights to different 
users, allows an organization or secure environment 
to provide differing permissions enabling different 
rights to users of the same content. 

3) A group of users could create a VDE document 
incrementally, by building it from individual 
contributions. These contributions would be bound 
together within a single controlled document, but 
each would be individually identified, for example, 
through their incorporation in VDE content 
containers as embedded container objects. 

4) VDE control and management capabilities could be 
used to track activities related to individual docu- 
ment areas, for instance recording how many times 
each section of a document was viewed. 

Example - VDE Protected Content Repository 

As the "Digital Highway" emerges, there is increased 
discussion concerning the distribution of content across networks 
and, in particular, public networks such as the Internet. Content 
may be made available across public networks in several ways 
including: 
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• "m ailing * content to a user in response to a request 
or advance purchase (sending a token representing 
the commitment of electronic funds or credit to 
purchase an item); 

• supporting content downloadable from an 
organization's own content repository, such a 
repository comprising, for example, a store of 
products (such as software programs) and/or a store 
of information resources, normally organized into 
one or more databases; and 

• supporting a public repository into which other 
parties can deposit their products for redistribution 
to customers (normally by making electronic copies 
for distribution to a customer in response to a 
request). 

One possible arrangement of VDE nodes involves use of 
one or more "repositories." A repository, for example, may serve 
as a location from which VDE participants may retrieve VDE 
content containers. In this case, VDE users may make use of a 
network to gain access to a - server" system that allows one or 
. more VDE users to access an object repository containing VDE 
content containers. 



Some VDE participants may create or provide content 
and/or VDE content container objects, and then store content 
and/or content objects at a repository so that other participants 
may access such content from a known and/or efficiently 
organized (for retrieval) location. For example, a VDE repository 
(portion of a VDE repository, multiple VDE repositories, and/or 
providers of content to such repositories) may advertise the 
availability of certain types of VDE protected content by sending 
out email to a list of network users. If the network users have 
secure VDE subsystems in their electronic appliances, they may 
then choose to access such a repository directly, or through one or 
more smart agents and, using an application program for 
example, browse (and/or electronically search) through the 
offerings of VDE managed content available at the repository, 
download desirable VDE content containers, and make use of 
such containers. If the repository is successful in attracting users 
who have an interest in such content, VDE content providers 
may determine that such a repository is a desirable locations) to 
make their content available for easy access by users. If a 
repository, such as CompuServe, stores content in non-encrypted 
(plaintext) form, it may encrypt "outgoing' content on an "as 
needed" basis through placing such content in VDE content 
containers with desired control information, and may employ 
VDE secure communications techniques for content 
communication to VDE participants. 



VDE repositories may also offer other VDE services. For 
example, a repository may choose to offer financial services in the 
form of credit from the repository that may be used to pay fees 
associated with use of VDE objects obtained from the repository. 
Alternatively or in addition, a VDE repository may perform audit 
information clearinghouse services on behalf of VDE creators or 
other participants (e.g. distributors, ^distributors, client 
administrators, etc.) for usage information reported by VDE 
users. Such services may include analyzing such usage 
information, creating reports, collecting payments, etc. 

A "full service" VDE repository may be very attractive to 
both providers and users of VDE managed content. Providers of 
VDE managed content may desire to place their content in a 
location that is well known to users, offers credit, and/or performs 
audit services for them. In this case, providers may be able to 
focus on creating content, rather than managing the 
administrative processes associated with making content 
available in a "retail" fashion, collecting audit information from 
many VDE users, sending and receiving bills and payments, etc. 
VDE users may find the convenience of a single location (or an 
integrated arrangement of repositories) appealing as they are 
attempting to locate content of interest. In addition, a full service 
VDE repository may serve as a single location for the reporting of 
usage information generated as a consequence of their use of 
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VDE managed content received from a VDE repository and/or, for 
example, receiving updated software (e.g. VDE-aware 
applications, load modules, component assemblies, non 
VDE-aware applications, etc.) VDE repository services may be 
employed in conjunction with VDE content delivery by broadcast 
and/or on physical media, such as CD-ROM, to constitute an 
integrated array of content resources that may be browsed, 
searched, and/or filtered, as appropriate, to fulfill the content 
needs of VDE users. 

A public repository system may be established and 
maintained as a non-profit or for-profit service. An organization 
offering the service may charge a service fee, for example, on a 
per transaction basis and/or as a percentage of the payments by, 
and/or cost of, the content to users. A repository service may 
supply VDE authoring tools to content creators, publishers, 
distributors, and/or value adding providers such that they may 
apply rules and controls that define some or all of the guidelines 
managing use of their content and so that they may place such 
content into VDE content container objects. 

A repository may be maintained at one location or may be 
distributed across a variety of electronic appliances, such as a 
variety of servers (e.g. video servers, etc.) which may be at 
different locations but nonetheless constitute a single resource. A 





VDE repository arrangement may employ VDE secure 
communications and VDE node secure subsystems ("protected 
processing environments"). The content comprising a given 
collection or unit of information desired by a user may be spread 
across a variety of physical locations. For example, content 
representing a company's closing stock price and the activity 
(bids, lows, highs, etc.) for the stock might be located at a World 
Wide Web server in New York, and content representing an 
analysis of the company (such as a discussions of the company's 
history, personnel, products, markets, and/or competitors) might 
be located on a server in Dallas. The content might be stored 
using VDE mechanisms to secure and audit vise. The content 
might be maintained in clear form if sufficient other forms of 
security are available at such one or more of sites (e.g. physical 
security, password, protected operating system, data encryption, 
or other techniques adequate for a certain content type). In the 
latter instances, content may be at least in part encrypted and 
placed in VDE containers as it streams out of a repository so as to 
enable secure communication and subsequent VDE usage control 
and usage consequence management. 

A user might request information related to such a 
company including stock and other information. This request 
might, for example, be routed first through a directory or a more 
sophisticated database arrangement located in Boston. This 



arrangement might contain pointers to, and retrieve content 
from, both the New York and Dallas repositories. This 
information content may, for example, be routed directly to the 
user in two containers (e.g. such as a VDE content container 
object from Dallas and a VDE content container object from New 
York). These twocontamersmayfoimtwoVDEobjectewitiiina 
single VDE container (which may contain two content objects 
containing the respective pieces of content from Dallas and New 
York) when processed by the user's electronic appliance. 
Alternatively, such objects might be integrated together to form a 
single VDE container in Boston so that the information can be 
delivered to the user within a single container to simplify 
registration and control at the user's site. The information 
content from both locations may be stored as separate 
information objects or they may be joined into a single, integrated 
information object (certain fields and/or categories in an 
information form or template may be filled in by one resource and 
other fields and/or categories may be filled by information 
provided by a different resource). A distributed database may 
manage such a distributed repository resource environment and 
use VDE to secure the storing, communicating, auditing, and/or 
use of information through VDE's electronic enforcement of VDE 
controls. VDE may then be used to provide both consistent 
. content containers and content control services. 
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An example of one possible repository arrangement 3300 is 
shown in Figure 78. In this example, a repository 3302 is 
connected to a network 3304 that allows authors 3306A, 3306B, 
3306C, and 3306D; a publisher 3308; and one or more end users 
3310 to communicate with the repository 3302 and with each 
other. A second network 3312 allows the publisher 3308, authors 
3306E and 3306F, an editor 3314, and a librarian 3316 to 
communicate with each other and with a local repository 3318. 
The publisher 3308 is also directly connected to author 3306E. In 
this example, the authors 3306 and publisher 3308 connect to the 
repository 3302 in order to place their content into an 
environment in which end users 3310 will be able to gain access 
to a broad selection of content from a common location. 

In this example, the repository has two major functional 
areas: a content system 3302A and a clearinghouse system 
3302B. The content system 3302A is comprised of a user/author 
registration system 3320, a content catalog 3322, a search 
mechanism 3324, content storage 3326, content references 3328, 
and a shipping system 3330 comprised of a controls packager 
3322, a container packager 3334, and a transaction system 3336. 
The clearinghouse system 3302B is comprised of a user/author 
registration system 3338; template libraries 3340; a control 
structure library 3342; a disbursement system 3344; an 
authorization system 3346 comprised of a financial system 3348 
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and a content system 3350; a billing system 3352 comprised of a 
paper system 3354, a credit card system 3356, and an electronic 
funds transfer (EFT) system 3358; and an audit system 3360 
comprised of a receipt system 3362, a response system 3364, a 
transaction system 3366, and an analysis system 3368. 

In this example, author 3306A creates content in electronic 
form that she intends to make broadly available to many end 
users 3310, and to protect her rights through use of VDE. Author 
3306A transmits a message to the repository 3302 indicating her 
desire to register with the repository to distribute her content. In 
response to this message, the user/author registration system 
3320 of the content system 3302A, and the user/author 
registration system 3338 of the clearinghouse system 3302B 
transmit requests for registration information to author 3306A 
using the network 3304. These requests may be made in an 
on-line interactive mode; or they may be transmitted in a batch to 
author 3306A who then completes the requested information and 
transmits it as a batch to the repository 3302; or some aspects 
may be handled on-line (such as basic identifying information) 
and other information may be exchanged in a batch mode. 



Registration information related to the content system 
3302A may, for example, include: 



a request that Author 3306A provide information 
concerning the types and/or categories of content 
proposed for storage and access using the repository, 

the form of abstract and/or other identifying 
information required by the repository — in addition 
to providing author 3306A with an opportunity to 
indicate whether or not author 3306A generally 
includes other information with content submissions 
(such as promotional materials, detailed information 
regarding the format of submitted content, any 
equipment requirements that should or must be met 
for potential users of submitted content to 
successfully exploit its value, etc,), 

requests for information from author 3306A 
concerning where the content is to be located (stored 
at the repository, stored at author 3306A's location, 
stored elsewhere, or some combination of locations), 

what general search characteristics should be 
associated with content submissions (e.g. whether 
abstracts should be automatically indexed for 
searches by users of the repository, the manner in 
which content titles, abstracts, promotional 
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control set 3154a may be used for a "trusted negotiation"; it 
references the desired negotiation CONTROL method 
("Negotiate") 3156 and references (in fields 3157 a, 3157b) two 
UDEs that this CONTROL method will use. These UDEs may 
be, for example, the PERCs 3100, 3125 shown in Figures 75A and 
75B. The second control set 3154b may be used by "multiple 
negotiation" processes to manage the negotiation, and may 
provide two negotiation methods: "Negotiatel," and "Negotiate2". 
Both negotiation processes may be described as required methods 
("Negotiatel" and "Negotiate2") 3156, 3158 that take respective 
PERCs 3100, 3125 as their inputs. The CONTROL method 3158 
for this control set in this example may specify the name of a 
service that the two negotiation processes will use to 
communicate with each other, and may also manage the creation 
of the URT resulting from the negotiation. 

When executed, the negotiation process(es) specified by the 
PERC 3150 shown in Figure 75C may be provided with the 
PERCs 3100, 3125 as input that will be used as the basis for 
negotiation. In this example, the choice of negotiation process 
type (trusted or multiple) may be made by the executing VDE 
node. The PERC 3150 shown in Figure 75C might be, for 
example, created by a REGISTER method in response to a 
• register request from a user. The process specified by this PERC 



3150 may then be used by a REGISTER method to initiate 
negotiation of the terms of an electronic contract. 

During this example negotiation process, the PERCs 3100, 
3125 shown in Figures 75A and 75B act as input data structures 
that are compared by a component assembly created based on 
PERC 3150 shown in Figure 35C. The component assembly 
specified by the control sets may be assembled and compared, 
starting with required "terms," and progressing to 
preferred/desired "terms" and then moving on to permitted 
"terms," as the negotiation continues. Method option selections 
are made using the desired method and method options specified 
in the PERCs 3100, 3125. In this example, a control set for the 
PERC 3100 shown in Figure 75A may be compared against the 
PERC 3125 shown in Figure 75B. If there is a "match," the 
negotiation is successfully concluded and "results" are generated. 

In this embodiment, the results of such negotiation will 
generally be written as a URT and "signed" by the negotiation 
process(es) to indicate that an agreement has been reached. 
These electronic signatures provide the means to show that a 
(virtual) r meeting of minds" was reached (one of the traditional 
legal preconditions for a contract to exist). An example of the 
URT 3160 that would have been created by the above example is 
shown in Figure 75D. 
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This URT 3160 (which may itself be a PERC 808) includes 
a control set 3162 that reflects the "terms" that were "agreed 
upon" in the negotiation. In this example, the "agreed upon" 
terms must "match" terms required by input PERCs 3100, 3125 
in the sense that they must be "as favorable as" the terms 
required by those PERCs. The negotiation result shown includes, 
for example, a "negotiated" control set 3162 that in some sense 
corresponds to the control set 3102a of the Figure 75A PERC 
3100 and to the control set 3131a of the Figure 75B control set 
3125. Resulting "negotiated" control set 3162 thus includes a 
required BUDGET method 3164 that corresponds to the control 
set 3125 desired BUDGET method 3142 but which is "within" the 
range of control sets allowed by control set 3100 required 
BUDGET method 3112. Similarly, resulting negotiated control 
set 3162 includes a required AUDIT method 3166 that complies 
with the requirements of both PERC 3100 required AUDIT 
method 3114 and PERC 3125 required AUDIT method 3135. 
Similarly, resulting negotiated control set 3162 includes a 
required BILLING method 3170 that "matches" or complies with 
each of PERC 3100 required BILLING method 3116 and PERC 
3125 required BILLING method 3170. 

Another class of negotiation is one under which no rules 
jare fixed and only the desired goals are specified. The 
negotiation processes for this type of negotiation may be very 



by host 2608 (except through and as permitted by the SPU). 
Looking at Figure 9 for a moment, RAM 2614 may be part of 
RAM 534 within the SPU 500, although it need not necessarily 
be contained within the same integrated circuit or other package 
that houses the rest of the SPU. 

Portable appliance 2600 RAM 534 may contain, for 
example, information which can be used to uniquely identify each 
instance of the portable appliance. This information may be 
employed (e.g. as at least a portion of key or password 
information) in authentication, verification, decryption, and/or 
encryption processes. 

Portable appliance 2600 may, in one embodiment, comprise 
means to perform substantially all of the functions of a VDE 
electronic appliance 600. Thus, for example, portable appliance 
2600 may include the means for storing and using permissions, 
methods, keys, programs, and/or other information, and can be 
capable of operating as a "stand alone" VDE node. 

In a further embodiment, portable appliance 2600 may 
perform preferred embodiment VDE functions once it has been 
coupled to an additional external electronic appliance 600. 
.Certain information, such as database management 
pennission(s), method(s), key(s), and/or other important 
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information (such as at least a portion of other VDE programs: 
administrative, user-interface, analysis, etc.) may be stored (for 
example as records) at an external VDE electronic appliance 600 
that may share information with portable appliance 2600. 

One possible "stand alone" configuration for 
tamper-resistant, portable appliance 2600 arrangements includes 
a tamper-resistant package (housing 2602) containing one or 
more processors (500, 2616) and/or other computing devices 
and/or other control logic, along with random-access-memory 
2614. Processors 500, 2616 may execute permissions and 
methods wholly (or at least in part) within the portable appliance 
2600. The portable appliance 2600 may have the ability to 
encrypt information before the information is communicated 
outside of the housing 2602 and/or decrypt received information 
when said received information is received from outside of the 
housing. This version would also possess the ability to store at 
least a portion of permission, method, and/or key information 
securely within said tamper resistant portable housing 2602 on 
non-volatile memory. 

Another version of portable appliance 2600 may obtain 
permissions and/or methods and/or keys from a local VDE 
electronic appliance 600 external to the portable appliance 2600 
to control, limit, or otherwise manage a user's use of a VDE 





protected object. Such a portable appliance 600 may be contained 
within, received by, installed in, or directly connected to, another 
electronic appliance 2600. 

One example of a "minimal" configuration of portable 
appliance 2600 would include only SPU 500 and batteiy 2612 
within homing 2602 (the external bus interface 2606 and the 
RAM 2614 would in this case each be incorporated into the SPU 
block shown in the Figure). In other, enhanced examples of 
portable appliance 2600, any or all of the following optional 
components may also be included within housing 2602: 
one or more CPUs 2616 (with associated support 

components such as RAM-ROM 2617, I/O controllers 
(not shown), etc.); 
one or more display devices 2618; 
one or more keypads or other user input buttons/control 

information 2620; 
one or more removable/replaceable memory device(s) 2622; 
and 

one or more printing device(s) 2624. 

In such more enhanced versions, the display 2618, keypad 2620, 
memory device 2622 and printer 2624 may be connected to bus 
2610, or they might be connected to CPU 2616 through an I/O 
port/controller portion (not shown) of the CPU. Display 2618 may 



be used to display information from SPU 500, CPU 2616 and/or 
host 2608. Keypad 2620 may be used to input information to 
SPU 500, CPU 2616 and/or host 2608. Printer 2624 may be used 
to print information from any/all of these sources. 
Removable/replaceable memory 2622 may comprise a memory 
cartridge or memory medium such as a bulk storage device, for 
providing additional long-term or short-term storage. Memory 
2622 may be easily removable from housing 2602 if desired. 

In one example embodiment, portable appliance 2600 may 
have the form factor of a "smart card a (although a "smart card" 
form factor may provide certain advantages, housing 2602 may 
have the same or different form factor as "conventional" smart 
cards). Alternatively, such a portable electronic appliance 2600 
may, for example, be packaged in a PCMCIA card configuration 
(or the like) which is currently becoming quite popular on 
personal computers and is predicted to become common for 
desk-top computing devices and Personal Digital Assistants. One 
advantageous form factor for the portable electronic appliance 
housing 2602 may be, for example, a Type 1, 2, or 3 PCMCIA 
card (or other derivations) having credit card or somewhat larger 
dimensions. Such a form factor is conveniently portable, and 
may be insertable into a wide array of computers and consumer 
.appliances, as well as receptacles at commercial establishments 
such as retail establishments and banks, and at public 
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communications points, such as telephone or other 
telecommunication "booths.* 

Housing 2602 may be insertable into and removable from a 
port, slot or other receptacle provided by host 2608 so as to be 
physically (or otherwise operatively) connected to a computer or 
other electronic appliance. The portable appliance connector 
2604 may be configured to allow easy removability so that 
appliance 2600 may be moved to another computer or other 
electronic appliance at a different location for a physical 
connection or other operative connection with that other device. 

Portable electronic appliance 2600 may provide a valuable 
and relatively simple means for a user to move permissions and 
methods between their (compatible) various electronic appliances 
600, such as between a notebook computer, a desktop computer 
and an office computer. It could also be used, for example, to 
allow a consumer to visit a next door neighbor and allow that 
neighbor to watch a movie that the consumer had acquired a 
license to view, or perhaps to listen to an audio record on a large 
capacity optical disk that the consumer had licensed for 
unlimited plays. 

Portable electronic appliance 2600 may also serve as a 
"smart card" for financial and other transactions for users to 
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materials, relevant dates, names of performers 
and/or authors, or other information related to 
content submissions may or should be used in lists of 
types of content and/or in response to searches, etc.), 
and/or 

• how content that is stored at and/or passed through 
the repository should be shipped (including any 
container criteria, encryption requirements, 
transaction requirements related to content 
transmissions, other control criteria, etc.) 

The information requested from author 3306A by the 
user/author registration system of the clearinghouse may, for 

example, consist of: 

• VDE templates that author 3306A may or must 
make use of in order to correctly format control 
information such that, for example, the audit system 
3360 of the clearinghouse system 3302B is properly 
authorized to receive and/or process usage 
information related to content submitted by author 
3306A, 

• VEE control information available from the 

clearinghouse 3302B that may or must be used by 



author 3306A (and/or included by reference) in some 
or all of the VDE component assemblies created 
and/or used by author 3306A associated with 
submitted content, 

the manner in which disbursement of any funds 
associated with usage of content provided by, passed 
through, or collected by the repository clearinghouse 
system 3302B should be made, 

the form and/or criteria of authorizations to use 
submitted content and/or financial transactions 
associated with content, 

the acceptable forms of billing for use of content 
and/or information associated with content (such as 
analysis reports that may be used by others), 

how VDE generated audit information should be 
received, 

how responses to requests from users should be 
managed, 
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• how transactions associated with the receipt of audit 
information should be formatted and authorized, 

• how and what forms of analysis should be performed 
on usage information, and/or 

• under what circumstances (if any) usage information 
and/or analysis results derived from VDE controlled 
content usage information should be managed 
(including to whom they may or must be delivered, 
the form of delivery, any control information that 
may be associated with use of such information, etc.) 

The repository 3302 receives the completed registration 
information from author 3306A and uses this information to 
build an account profile for author 3306A. In addition, software 
associated with the authoring process may be transmitted to 
author 3306A. This software may, for example, allow author 
3306A to place content into a VDE content container with 
appropriate controls in such a way that many of the decisions 
associated with creating such containers are made automatically 
to reflect the use of the repository 3302 as a content system 
and/or a clearinghouse system (for example, the location of 
content, the party to contact for updates to content and/or 
controls associated with content, the party or parties to whom 



audit information may and/or must be transmitted and the 
pathways for such communication, the character of audit 
information that is collected during usage, the forms of payment 
that are acceptable for use of content, the frequency of audit 
transmissions required, the frequency of billing, the form of 
abstract and/or other identifying information associated with 
content, the nature of at least a portion of content usage control 
information, etc,) 

Author 3306A makes use of a VDE authoring application 
to specify the controls and the content that she desires to place 
within a VDE content container, and produces such a container 
in accordance with any requirements of the repository 3302. 
Such a VDE authoring application may be, for example, an 
application provided by the repository 3302 which can help 
ensure adherence to repository content control requirements such 
as the inclusion of one or more types of component assemblies or 
other VDE control structures and/or required parameter data, an 
application received from another party, and/or an application 
created by author 3306A in whole or in part. Author 3306A then 
uses the network 3304 to transmit the container and any 
deviations from author 3306A's account profile that may relate to 
such content to the repository 3302. The repository 3302 receives 
the submitted content, and then - in accordance with any 
account profile requirements, deviations and/or desired options in 
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this example — makes a determination as to whether the content 
was produced within the boundaries of any content and/or control 
information requirements of the repository and therefore should 
be placed within content storage or referenced by a location 
pointer or the like. In addition to placing the submitted content 
into content storage or referencing such content's location, the 
repository 3302 may also make note of characteristics associated 
with such submitted content in the search mechanism 3324, 
content references 3328, the shipping system 3330, and/or the 
relevant systems of the clearinghouse system 3302B related to 
templates and control structures, authorizations, billing and/or 
payments, disbursements, and/or audits of usage information* 

During an authoring process, author 3306A may make use 
of VDE templates. Such templates may be used as an aspect of a 
VDE authoring application. For example, such templates may be 
used in the construction of a container as described above. 
Alternatively or in addition, such templates may also be used 
when submitted content is received by the repository 3302. 
References to such templates may be incorporated by author 
3306A as an aspect of constructing a container for submitted 
content (in this sense the container delivered to the repository 
may be in some respects "incomplete" until the repository 
"completes" the container through use of indicated templates). 
Such references may be required for use by the repository 3302 



(for example, to place VDE control information in place to fulfill 
an aspect of the repository's business or security models such as 
one or more map tables corresponding to elements of content 
necessary for interacting with other VDE control structures to 
accommodate certain metering, billing, budgeting, and/or other 
usage and/or distribution related controls of the repository). 

For example, if content submitted by author 3306A 
consists of a periodical publication, a template delivered to the 
author by the repository 3302 when the author registers at the 
repository may be used as an aspect of an authoring application 
manipulated by the author in creating a VDE content container 
for such a periodical. Alternatively or in addition, a template 
designed for use with periodical publications may be resident at 
the repository 3302, and such a template may be used by the 
repository to define, in whole or in part, control structures 
associated with such a container. For example, a VDE template 
designed to assist in formulating control structures for periodical 
publications might indicate (among other things) that: 

• usage controls should include a meter method that 
records each article within a publication that a user 
opens, 



• a certain flat rate fee should apply to opening the 
periodical regardless of the number of articles 
opened, and/or 

• a record should be maintained of every 
advertisement that is viewed by a user. 

If content is maintained in a known and/or identifiable format, 
such a template may be used during initial construction of a 
container without author 3306A's intervention to identify any 
map tables that may be required to support such recording and 
billing actions. If such a VDE template is unavailable to author 
3306A, she may choose to indicate that the container submitted 
should be reconstructed (e.g. augmented) by the repository to 
include the VDE control information specified in a certain 
template or class of templates. If the format of the content is 
known and/or identifiable by the repository, the repository may 
be able to reconstruct (or "complete ') such a container 
automatically. 

One factor in a potentially ongoing financial relationship 
between the repository and author 3306A may relate to usage of 
submitted content by end users 3310. For example, author 
3306A may negotiate an arrangement with the repository 
wherein the repository is authorized to keep 20% of the total 
revenues generated from end users 3310 in exchange for 



maintaining the repository services (e.g. making content 
available to end users 3310, providing electronic credit, 
performing billing activities, collecting fees, etc,) A financial 
relationship may be recorded in control structures in flexible and 
configurable ways. For example, the financial relationship 
described above could be created in a VDE container and/or 
installation control structure devised by author 3306A to reflect 
author 3306A's financial requirements and the need for a 20% 
split in revenue with the repository wherein all billing activities 
related to usage of submitted content could be processed by the 
repository, and control structures representing reciprocal 
methods associated with various component assemblies required 
for use of author 3306A's submitted content could be used to 
calculate the 20% of revenues. Alternatively, the repository may 
independently and securely add and/or modify control structures 
originating from author 3306A in order to reflect an increase in 
price. Under some circumstances, author 3306A may not be 
directly involved (or have any knowledge of) the actual price that 
the repository charges for usage activities, and may concern 
herself only with the amount of revenue and character of usage 
analysis information that she requires for her own purposes, 
which she specifies in VDE control information which governs the 
use, and consequences of use, of VDE controlled content. 



Another aspect of the relationship between authors and 
the repository may involve the character of transaction recording 
requirements associated with delivery of VDE controlled content 
and receipt of VDE controlled content usage audit information. 
For example, author 3306A may require that the repository make 
a record of each user that receives a copy of content from the 
repository. Author 3306A may further require collection of 
information regarding the circumstances of delivery of content to 
such users (e.g. time, date, etc.) In addition, the repository may 
elect to perform such transactions for use internally (e.g. to 
determine patterns of usage to optimize systems, detect fraud, 
etc.) 

In addition to recording information regarding delivery of 
such VDE controlled content, author 3306A may have required or 
requested the repository to perform certain VDE container 
related processes. For example, author 3306A may want 
differing abstract and/or other descriptive information delivered 
to different classes of users. In addition, author 3306A may wish 
to deliver promotional materials in the same container as 
submitted content depending on, for example, the character of 
usage exhibited by a particular user (e.g. whether the user has 
ever received content from author 3306A, whether the user is a 
regular subscriber to author 3306A's materials, and/or other 
patterns that may be relevant to author 3306A and/or the end 



user that are used to help determine the mix of promotional 
materials delivered to a certain VDE content end user.) In 
another example, author 3306A may require that VDE 
fingerprinting be performed on such content prior to 
transmission of content to an end user. 

In addition to the form and/or character of content shipped 
to an end user, authors may also require certain encryption 
related processes to be performed by the repository as an aspect 
of delivering content. For example, author 3306A may have 
required that the repository encrypt each copy of shipped content 
using a different encryption key or keys in order to help maintain 
greater protection for content (e.g. in case an encryption key was 
"cracked" or inadvertently disclosed, the "damage" could be 
limited to the portion(s) of that specific copy of a certain content 
deliverable). In another example, encryption functions may 
include the need to use entirely different encryption algorithms 
and/or techniques in order to fulfill circumstantial requirements 
(e.g. to comply with export restrictions). In a further example, 
encryption related processes may include changing the 
encryption techniques and/or algorithms based on the level of 
trustedness and/or tamper resistance of the VDE site to which 
content is delivered. 



In addition to transaction information gathered when 
content is shipped from a VDE repository to an end user, the 
repository may be required to keep transaction information 
related to the receipt of usage information, requests, and/or 
responses to and/or from end users 3310. For example, author 
3306A may require the repository to keep a log of some or all 
connections made by end users 3310 related to transmissions and 
or reception of information related to the use of author 3306A's 
content (e.g. end user reporting of audit information, end user 
requests for additional permissions information, etc.) 

Some VDE managed content provided to end users 3310 
through the repository may be stored in content storage. Other 
information may be stored elsewhere, and be referenced through 
the content references. In the case where content references are 
used, the repository may manage the user interactions in such a 
manner that all repository content, whether stored in content 
storage or elsewhere (such as at another site), is presented for 
selection by end users 3310 in a uniform way, such as, for 
example, a consistent or the same user interface. If an end user 
requests delivery of content that is not stored in content storage, 
the VDE repository may locate the actual storage site for the 
content using information stored in content references (e.g. the 
network address where the content may be located, a URL, a 
filesystem reference, etc.) After the content is located, the 



content may be transmitted across the network to the repository 
or it may be delivered directly from where it is stored to the 
requesting end user. In some circumstances (e.g. when container 
modification is required, when encryption must be changed, if 
financial transactions are required prior to release, etc.), further 
processing may be required by the repository in order to prepare 
such VDE managed content and/or VDE content container for 
transmission to an end user. 

In order to provide a manageable user interface to the 
content available to VDE repository end users 3310 and to 
provide administrative information used in the determination of 
control information packaged in VDE content containers shipped 
to end users 3310, the repository in this example includes a 
content catalog 3322. This catalog is used to record information 
related to the VDE content in content storage, and/or content 
available through the repository reflected in content references. 
The content catalog 3322 may consist of titles of content, 
abstracts, and other identifying information. In addition, the 
catalog may also indicate the forms of electronic agreement 
and/or agreement VDE template applications (offering optional, 
selectable control structures and/or one or more opportunities to 
provide related parameter data) that are available to end users 
3310 through the repository for given pieces of content in 
deciding, for example, options and/or requirements for: what 



type(s) of information ia recorded during such content's use, the 
charge for certain content usage activities, differences in charges 
based on whether or not certain usage information is recorded 
and/or made available to the repository and/or content provider, 
the redistribution rights associated with such content, the 
reporting frequency for audit transmissions, the forms of credit 
and/or cuiTency that may be used to pay certain fees associated 
with use of such content, discounts related to certain volumes of 
usage, discounts available due to the presence of rights 
associated with other content from the same and/or different 
content providers, sales, etc. Furthermore, a VDE repository 
content catalog 3322 may indicate some or all of the component 
assemblies that are required in order to make use of content such 
that the end user's system and the repository can exchange 
messages to help ensure that any necessary VDE component 
assemblies or other VDE control information is identified, and if 
necessary and authorized, are delivered along with such content 
to the end user (rather than, for example, being requested later 
after their absence has been detected during a registration and/or 
use attempt). 

In order to make use of the VDE repository in this 
example, an end user must register with the repository. In a 
manner similar to that indicated above in the case of an author, a 
VDE end user transmits a message from her VDE installation to 
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the repository across the network indicating that she wishes to 
make use of the services provided by the repository (e.g. access 
content stored at and/or referenced by the repository, use credit 
provided by the repository, etc.) In response to this message, the 
user/author registration systems of the content system 3302A 
and the clearinghouse system 3302B of the repository transmit 
requests for information from the end user (e.g. in an on-line 
and/or batch interaction). The information requested by the 
user/author registration system of the content system 3302A may 
include type(s) of content that the user wishes to access, the 
characteristics of the user's electronic appliance 600, etc. The 
information requested by the user/author registration system of 
the clearinghouse system 3302B may include whether the user 
wishes to establish a credit account with the clearinghouse 
system 3302B, what other forms of credit the user may wish to 
use for billing purposes, what other clearinghouses may be used 
by the end user in the course of interacting with content obtained 
from the repository, any general rules that the user has 
established regarding their preferences for release and handling 
of usage analysis information, etc. Once the end user has 
completed the registration information and transmitted it to the 
repository, the repository may construct an account profile for the 
user. In this example, such requests and responses are handled 
by secure VDE communications between secure VDE subsystems 
of both sending and receiving parties. 



In order to make use of the repository, the end user may 
operate application software. In this example, the end user may 
either make use of a standard application program (e.g. a World 
Wide Web browser such as Mosaic), or they may make use of 
application software provided by the repository after completion 
of the registration process. If the end user chooses to make use of 
the application software provided by the repository, they may be 
able to avoid certain complexities of interaction that may occur if 
a standard package is used. Although standardized packages are 
often relatively easy to use, a customized package that 
incorporates VDE aware functionality may provide an easier to 
use interface for a user. In addition, certain characteristics of the 
repository may be built in to the interface to simplify use of the 
services (e.g. similar to the application programs provided by 
America Online). 

The end user may connect to the repository using the 
network. In this example, after the user connects to the 
repository, an authentication process will occur. This process can 
either be directed by the user (e.g. through use of a login and 
password protocol) or may be established by the end user's 
electronic appliance secure subsystems interacting with a 
repository electronic appliance in a VDE authentication. In 
either event, the repository and the user must initially ensure 
that they are connected to the correct other party. In this 



example, if secured information will flow between the parties, a 
VDE secured authentication must occur, and a secure session 
must be established. On the other hand, if the information to be 
exchanged has already been secured and/or is available without 
authentication (e.g. certain catalog information, containers that 
have already been encrypted and do not require special handling, 
etc.), the "weaker" form of login/password may be used. 

Once an end user has connected to the VDE repository and 
authentication has occurred, the user may begin manipulating 
and directing their user interface software to browse through a 
repository content catalog 3322 (e.g. lists of publications, 
software, games, movies, etc.), use the search mechanism to help 
locate content of interest, schedule content for delivery, make 
inquiries of account status, availability of usage analysis 
information, billing information, registration and account profile 
information, etc. If a user is connecting to obtain content, the 
usage requirements for that content may be delivered to them. If 
the user is connecting to deliver usage information to the 
repository, information related to that transmission may be 
delivered to them. Some of these processes are described in more 
detail below. 

In this example, when an end user requests content from 
the VDE repository (e.g. by selecting from a menu of available 
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options), the content system 3302A locates the content either in 
the content references and/or in content storage. The content 
system 3302A may then refer to information stored in the content 
catalog 3322, the end user's account profile, and/or the author's 
account profile to determine the precise nature of container 
format and/or control information that may be required to create 
a VDE content container to fulfill the end user's request. The 
shipping system then accesses the clearinghouse system 3302Bto 
gather any necessary additional control structures to include 
with the container, to determine any characteristics of the 
author's and/or end user's account profiles that may influence 
either the transaction^) associated with delivering the content to 
the end user or with whether the transaction may be processed. 
If the transaction is authorized, and all elements necessary for 
the container are available, the controls packager forms a 
package of control information appropriate for this request by 
this end user, and the container packager takes this package of 
control information and the content and forms an appropriate 
container (including any permissions that may be codeliverable 
with the container, incorporating any encryption requirements, 
etc.) If required by the repository or the author's account profile, 
transactions related to delivery of content are recorded by the 
transaction system of the shipping system. When the container 
. and any transactions related to delivery have been completed, 
the container is transmitted across the network to the end user. 



An end riser may make use of credit and/or currency 
securely stored within the end user's VDE installation secure 
subsystem to pay for charges related to use of VDE content 
received from the repositoiy, and/or the user may maintain a 
secure credit and/or currency account remotely at the repository, 
including a "virtual" repository where payment is made for the 
receipt of such content by an end user. This later approach may 
provide greater assurance for payment to the repository and/or 
content providers particularly if the end user has only an HPE 
based secure subsystem. If an end user electronic credit and/or 
currency account is maintained at the repository in this example, 
charges are made to said account based on end user receipt of 
content from the repository. Further charges to such a remote 
end user account may be made based on end user usage of such 
received content and based upon content usage information 
communicated to the repository clearinghouse system 3302B. 

In this example, if an end user does not have a relationship 
established with a financial provider (who has authorized the 
content providers whose content may be obtained through use of 
the repository to make use of their currency and/or credit to pay 
for any usage fees associated with such provider's content) and/or 
if an end user desires a new source of such credit, the end user 
may request credit from the repository clearinghouse system 
3302B. If an end user is approved for credit, the repository may 



extend credit in the form of credit amounts (e.g. recorded in one 
or more UDEs) associated with a budget method managed by the 
repository. Periodically, usage information associated with such a 
budget method is transmitted by the end user to the audit system 
of the repository. After such a transmission (but potentially 
before the connection is terminated), an amount owing is 
recorded for processing by the billing system, and in accordance 
with the repository's business practices, the amount of credit 
available for use by the end user may be replenished in the same 
or subsequent transmission. In this example, the clearinghouse 
of the repository supports a billing system with a paper system 
for resolving amounts owed through the mail, a credit card 
system for resolving amounts owed through charges to one or 
more credit cards, and an electronic funds transfer system for 
resolving such amounts through direct debits to a bank account. 
The repository may automatically make payments determined by 
the disbursement system for monies owed to authors through use 
of similar means. Additional detail regarding the audit process is 
provided below. 

As indicated above, end users 3310 in this example will 
periodically contact the VDE repository to transmit content usage 
information (e.g. related to consumption of budget, recording of 
other usage activities, etc.), replenish their budgets, modify their 
account profile, access usage analysis information, and perform 



other administrative and information exchange activities. In 
some cases, an end user may wish to contact the repository to 
obtain additional control structures. For example, if an end user 
has requested and obtained a VDE content container from the 
repository, that container is typically shipped to the end user 
along with control structures appropriate to the content, the 
author's requirements and account profile, the end user's account 
profile, the content catalog 3322, and/or the circumstances of the 
delivery (e.g. the first delivery from a particular author, a 
subscription, a marketing promotion, presence and/or absence of 
certain advertising materials, requests formulated on behalf of 
the user by the user's local VDE instance, etc.) Even though, in 
this example, the repository may have attempted to deliver all 
relevant control structures, some containers may include controls 
structures that allow for options that the end user did not 
anticipate exercising (and the other criteria did not automatically 
select for inclusion in the container) that the end user 
nonetheless determines that they would like to exercise. In this 
case, the end user may wish to contact the repository and request 
any additional control information (including, for example, 
control structures) that they will need in order to make use of the 
content under such option. 

For example, if an end user has obtained a VDE content 
container with an overall control structure that includes an 



option that records of the number of times that certain types of 
accesses are made to the container and further bases usage fees 
on the number of such accesses, and another option within the 
overall control structure allows the end user to base the fees paid 
for access to a particular container based on the length of time 
spent using the content of the container, and the end user did not 
originally receive controls that would support this latter form of 
usage, the repository may deliver such controls at a later time 
and when requested by the user. In another example, an author 
may have made changes to their control structures (e.g. to reflect 
a sale, a new discounting model, a modified business strategy, 
etc.) which a user may or must receive in order to use the content 
container with the changed control structures. For example, one 
or more control structures associated with a certain VDE content 
container may require a "refresh" for continued authorization to 
employ such structures, or the control structures may expire. 
This allows (if desired) a VDE content provider to periodically 
modify and/or add to VDE control information at an end user's 
site (employing the local VDE secure subsystem). 

Audit information (related to usage of content received 
from the repository) in this example is securely received from end 
users 3310 by the receipt system 3362 of the clearinghouse. As 
indicated above, this system may process the audit information 
and pass some or all of the output of such a process to the billing 



system and/or transmit such output to appropriate content 
authors. Such passing of audit information employs secure VDE 
pathway of reporting information handling techniques. Audit 
information may also be passed to the analysis system in order to 
produce analysis results related to end user content usage for use 
by the end user, the repository, third party market researchers, 
and/or one or more authors. Analysis results may be based on a 
single audit transmission, a portion of an audit transmission, a 
collection of audit transmissions from a single end user and/or 
multiple end users 3310, or some combination of audit 
transmissions based on the subject of analysis (e.g. usage 
patterns for a given content element or collection of elements, 
usage of certain categories of content, payment histories, 
demographic usage patterns, etc.) The response system 3364 is 
used to send information to the end user to, for example, 
replenish a budget, deliver usage controls, update permissions 
information, and to transmit certain other information and/or 
messages requested and/or required by an end user in the course 
of their interaction with the clearinghouse. During the course of 
an end user's connections and transmissions to and from the 
clearinghouse, certain transactions (e.g. time, date, and/or 
purpose of a connection and/or transmission) may be recorded by 
the transaction system of the audit system to reflect 
requirements of the repository and/or authors. 



Certain audit information may be transmitted to authors. 
For example, author 3306A may require that certain information 
gathered from an end user be transmitted to author 3306A with 
no processing by the audit system. In this case, the fact of the 
transmission may be recorded by the audit system, but author 
3306A may have elected to perform their own usage analysis 
rather than (or in addition to) permitting the repository to access, 
otherwise process and/or otherwise use this information. The 
repository in this example may provide author 3306A with some 
of the usage information related to the repository's budget 
method received from one or more end users 3310 and generated 
by the payment of fees associated with such users' usage of 
content provided by author 3306A . In this case, author 3306A 
may be able to compare certain usage information related to 
content with the usage information related to the repository's 
budget method for the content to analyze patterns of usage (e.g. 
to analyze usage in light of fees, detect possible fraud, generate 
user profile information, etc.) Any usage fees collected by the 
clearinghouse associated with author 3306A's content that are 
due to author 3306A will be determined by the disbursement 
system of the clearinghouse. The disbursement system may 
include usage information (in complete or summary form) with 
any payments to author 3306A resulting from such a 
determination. Such payments and information reporting may 
be an entirely automated sequence of processes occurring within 



the VDE pathway firom end user VDE secure subsystems, to the 
clearinghouse secure subsystem, to the author's secure 
subsystem* 

In this example, end users 3310 may transmit VDE 
permissions and/or other control information to the repository 
3302 permitting and/or denying access to usage information 
collected by the audit system for use by the analysis system. 
This, in part, may help ensure end user's privacy rights as it 
relates to the usage of such information. Some containers may 
require, as an aspect of their control structures, that an end user 
make usage information available for analysis purposes. Other 
containers may give an end user the option of either allowing the 
usage information to be used for analysis, or denying some or all 
such uses of such information. Some users may elect to allow 
analysis of certain information, and deny this permission for 
other information. End users 3310 in this example may, for 
example, elect to limit the granularity of information that may be 
used for analysis purposes (e.g. an end user may allow analysis of 
the number of movies viewed in a time period but disallow use of 
specific titles, an end user may allow release of their ZIP code for 
demographic analysis, but disallow use of their name and 
address, etc.) Authors and/or the repository 3302 may, for 
example, choose to charge end users 3310 smaller fees if they 
agree to release certain usage information for analysis purposes. 



In this example, the repository 3302 may receive content 
produced by more than one author. For example, author B, 
author C, and author D may each create portions of content that 
will be delivered to end users 3310 in a single container. For 
example, author B may produce a reference work. Author C may 
produce a commentary on author B's reference work, and author 
D may produce a set of illustrations for author B's reference work 
and author C's commentary. Author B may collect together 
author C's and author D's content and add further content (e.g. 
the reference work described above) and include such content in a 
single container which is then transmitted to the repository 3302. 
Alternatively, each of the authors may transmit their works to 
the repository 3302 independently, with an indication that a 
template should be used to combine their respective works prior 
to shipping a container to an end user. Still alternatively, a 
container reflecting the overall content structure may be 
transmitted to the repository 3302 and some or all of the content 
may be referenced in the content references rather than delivered 
to the repository 3302 for storage in content storage. 

When an end user makes use of container content, their 
content usage information may, for example, be segregated in 
accordance with control structures that organize usage 
information based at least in part on the author who created that 
segment. Alternatively, the authors and/or the VDE repository 



3302 may negotiate one or more other techniques for securely 
dividing and/or sharing usage information in accordance with 
VDE control information* Furthermore, control structures 
associated with a container may implement models that 
differentiate any usage fees associated with portions of content 
based on usage of particular portions, overall usage of the 
container, particular patterns of usage, or other mechanism 
negotiated (or otherwise agreed to) hy the authors. Reports of 
usage information, analysis results, disbursements, and other 
clearinghouse processes may also be generated in a manner that 
reflects agreements reached by repository 3302 participants 
(authors, end users 3310 and/or the repository 3302) with respect 
to such processes. These agreements may be the result of a VDE 
control information negotiation amongst these participants. 

In this example, one type of author is a publisher 3308. 
The publisher 3308 in this example communicates over an 
' internal" network with a VDE based local repository 3302 and 
over the network described above with the public repository 3302. 
The publisher 3308 may create or otherwise provide content 
and/or VDE control structure templates that are delivered to the 
local repository 3302 for use by other participants who have 
access to the "internal" network. These templates may be used to 
describe the structure of containers, and may further describe 
whom in the publisher 3308's organization may take which 



actions with respect to the content created within the 
organization related to publication for delivery to (and/or 
referencing by) the repository 3302. For example, the publisher 
3308 may decide (and control by use of said temple) that a 
periodical publication will have a certain format with respect to 
the structure of its content and the types of information that may 
be included (e.g. text, graphics, multimedia presentations, 
advertisements, etc.), the relative location and/or order of 
presentation of its content, the length of certain segments, etc. 
Furthermore, the publisher 3308 may, for example, determine 
(through distribution of appropriate permissions) that the 
publication editor is the only party that may grant permissions to 
write into the container, and that the organization librarian is 
the only party that may index and/or abstract the content. In 
addition, the publisher 3308 may, for example, allow only certain 
one or more parties to finalize a container for delivery to the 
repository 3302 in usable form (e.g. by mamtaining control over 
the type of permissions, including distribution permissions, that 
may be required by the repository 3302 to perform subsequent 
distribution activities related to repository end users 3310). 

In this example, author 3306E is connected directly to the 
publisher 3308, such that the publisher 3308 can provide 
templates for that author that establish the character of 
containers for author 3306E's content. For example, if author 



3306E creates books for distribution by the publisher 3308, the 
publisher 3308 may define the VDE control structure template 
which provides control method options for author 3306E to select 
from and which provides VDE control structures for securely 
distributing author 3306E's works. Author 3306E and the 
publisher 3308 may employ VDE negotiations for the template 
characteristics, specific control structures, and/or parameter data 
used by author 3306E. Author 3306E may then use the 
template(s) to create control structures for their content 
containers. The publisher 3308 may then deliver these works to 
the repository 3302 under a VDE extended agreement comprising 
electronic agreements between author 3306E and the publisher 
3308 and the repository 3302 and the publisher 3308. 

In this example, the publisher 3308 may also make author 
3306E's work available on the local repository 3302. The editor 
may authorize (e.g. through distribution of appropriate 
permissions) author F to create certain portions of content for a 
publication. In this example, the editor may review and/or 
modify author Fs work and further include it in a container with 
content provided by author 3306E (available on the local 
repository 3302). The editor may or may not have permissions 
from the publisher 3308 to modify author 3306E's content 
(depending on any negotiation(s) that may have occurred 
between the publisher 3308 and author 3306E, and the publisher 



3308's decision to extend such rights to the editor if permissions 
to modify author 3306E's content are held in redistributable form 
by the publisher 3308). The editor may also include content from 
other authors by (a) using a process of granting permissions to 
authors to write directly into the containers and/or (b) retrieving 
containers from the local repository 3302 for inclusion. The local 
repository 3302 may also be used for other material used by the 
publisher 3308's organization (e.g. databases, other reference 
works, internal documents, draft works for review, training 
videos, etc.), such material may, given appropriate permissions, 
be employed in VDE container collections of content created by 
the editor. 

The librarian in this example has responsibility for 
building and/or editing inverted indexes, keyword lists (e.g. from 
a restricted vocabulary), abstracts of content, revision histories, 
etc. The publisher 3308 may, for example, grant permissions to 
only the librarian for creating this type of content. The publisher 
3308 may farther require that this building and/or editing occur 
prior to release of content to the repository 3302. 



Example — Evolution and Transformation of VDE Managed 
Content and Control Information 

The VDE content control architecture allows content 
control information (such as control information for governing 
content usage) to be shaped to conform to VDE control 
information requirements of multiple parties. Formulating such 
multiple party content control information normally involves 
securely deriving control information from control information 
securely contributed by parties who play a role in a content 
handling and control model (e.g. content creators), providers), 
user(s), cleaiinghouse(s), etc.). Multiple party control 
information may be necessary in order to combine multiple pieces 
of independently managed VDE content into a single VDE 
container object (particularly if such independently managed 
content pieces have differing, for example conflicting, content 
control information). Such secure combination of VDE managed 
pieces of content will frequently require VDE's ability to securely 
derive content control information which accommodates the 
control information requirements, including any combinatorial 
rules, of the respective VDE managed pieces of content and 
reflects an acceptable agreement between such plural control 
information sets. 



The combination of VDE managed content pieces may 
result in a VDE managed composite of content. Combining VDE 



managed content must be carried out in accordance with relevant 
content control information associated with said content pieces 
and processed through the use of one or more secure VDE 
sub-system PPEs 650. VDE's ability to support the embedding, 
or otherwise combining, of VDE managed content pieces, so as to 
create a combination product comprised of various pieces of VDE 
content, enables VDE content providers to optimize their VDE 
electronic content products. The combining of VDE managed 
content pieces may result in a VDE content container which 
"holds" consolidated content and/or concomitant, separate, nested 
VDE content containers. 

VDE's support for creation of content containers holding 
distinct pieces of VDE content portions that were previously 
managed separately allows VDE content providers to develop 
products whose content control information reflects value 
propositions consistent with the objectives of the providers of 
content pieces, and further are consistent with the objectives of a 
content aggregator who may be producing a certain content 
combination as a product for commercial distribution. For 
example, a content product "launched" by a certain content 
provider into a commercial channel ( such as a network 
repository) may be incorporated by different content providers 
and/or end-users into VDE content containers (so long as such 
incorporation is allowed by the launched product's content 



control information). These different content providers and/or 
end-users may, for example, submit differing control information 
for regulating use of such content. They may also combine in 
different combinations a certain portion of launched content with 
content received from other parties (and/or produced by 
themselves) to produce different content collections, given 
appropriate authorizations. 

VDE thus enables copies of a given piece of VDE managed 
content to be securely combined into differing consolidations of 
content, each of which reflects a product strategy of a different 
VDE content aggregator. VDE's content aggregation capability 
will result in a wider range of competitive electronic content 
products which offer differing overall collections of content and 
may employ differing content control information for content that 
may be common to such multiple products. Importantly, VDE 
securely and flexibly supports editing the content in, extracting 
content from, embedding content into, and otherwise shaping the 
content composition of, VDE content containers. Such capabilities 
allow VDE supported product models to evolve by progressively 
reflecting the requirements of "next* 1 participants in an electronic 
commercial model. As a result, a given piece of VDE managed 
content, as it moves through pathways of handling and 
branching, can participate in many different content container 
and content control information commercial models. 



VDE content, and the electronic agreements associated 
with said content, can be employed and progressively 
manipulated in commercial ways which reflect traditional 
business practices for non-electronic products (though VDE 
supports greater flexibility and efficiency compared with most of 
such traditional models). Limited only by the VDE control 
information employed by content creators, other providers, and 
other pathway of handling and control participants, VDE allows 
a 'natural" and unhindered flow of, and creation of, electronic 
content product models. VDE provides for this flow of VDE 
products and services through a network of creators, providers, 
and users who successively and securely shape and reshape 
product composition through content comb ining , extracting, and 
editing within a Virtual Distribution Environment. 

VDE provides means to securely combine content provided 
at different times, by differing sources, and/or representing 
differing content types. These types, timings, and/or different 
sources of content can be employed to form a complex array of 
content within a VDE content container. For example, a VDE 
content container may contain a plurality of different content 
container objects, each containing different content whose usage 
can be controlled, at least in part, by its own container's set of 
VDE content control information. 



A VDE content container object may, through the use of a 
secure VDE sub-system, be "safely** embedded within a "parent" 
VDE content container. This embedding process may involve the 
creation of an embedded object, or, alternatively, the containing, 
within a VDE content container, of a previously independent and 
now embedded object by, at minimum, appropriately referencing 
said object as to its location. 

An embedded content object within a parent VDE content 
container: 

(1) may have been a previously created VDE content 
container which has been embedded into a parent VDE 
content container by securely transforming it from an 
independent to an embedded object through the secure 
processing of one or more VDE component assemblies 
within a VDE secure sub-system PPE 650. In this 
instance, an embedded object may be subject to content 
control information, including one or more permissions 
records associated with the parent container, but may not, 
for example, have its own content control information other 
than content identification information, or the embedded 
object may be more extensively controlled by its own 
content control information (e.g. permissions records). 



(2) may include content which was extracted from 
another VDE content container (along with content control 
information, as may be applicable) for inclusion into a 
parent VDE content container in the form of an embedded 
VDE content container object. In this case, said extraction 
and embedding may use one or more VDE processes which 
run securely within a VDE secure sub-system PPE 650 and 
which may securely remove (or copy) the desired content 
from a source VDE content container and place such 
content in a new or existing container object, either of 
which may be or become embedded into a parent VDE 
content container. 

(3) may include content which was first created and 
then placed in a VDE content container object. Said 
receiving container may already be embedded in a parent 
VDE content container and may already contain other 
content. The container in which such content is placed 
may be specified using a VDE aware application which 
interacts with content and a secure VDE subsystem to 
securely create such VDE container and place such content 
therein followed by securely embedding such container into 
the destination, parent container. Alternatively, content 
may be specified without the use of a VDE aware 
application, and then manipulated using a VDE aware 



application in order to manage movement of the content 
into a VDE content container. Such an application may be 
a VDE aware word processor, desktop and/or multimedia 
publishing package, graphics and/or presentation package, 
etc. It may also be an operating system function (e.g. part 
of a VDE aware operating system or mini-application 
operating with an O/S such as a Microsoft Windows 
compatible object packaging application) and movement of 
content from "outside" VDE to within a VDE object may, 
for example, be based on a "drag and drop" metaphor that 
involves "dragging" a file to a VDE container object using a 
pointing device such as a mouse. Alternatively, a user may 
"cut" a portion of content and "paste" such a portion into a 
VDE container by first placing content into a "clipboard," 
then selecting a target content object and pasting the 
content into such an object. Such processes may, at the 
direction of VDE content control information and under the 
control of a VDE secure subsystem, put the content 
automatically at some position in the target object, such as 
at the end of the object or in a portion of the object that 
corresponds to an identifier carried by or with the content 
such as a field identifier, or the embedding process might 
pop-up a user interface that allows a user to browse a 
target objects contents and/or table of contents and/or 
other directories, indexes, etc. Such processes may farther 
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allow a user to make certain decisions concerning VDE 
content control information (budgets limiting use, 
reporting pathway(s), usage registration requirements, 
etc.) to be applied to such embedded content and/or may 
involve selecting the specific location for embedding the 
content, all such processes to be performed as 
transparently as practical for the application. 

(4) may be accessed in conjunction with one or more 
operating system utilities foi»object embedding and 
linking, such as utilities conforming to the Microsoft OLE 
standard. In this case, a VDE container may be associated 
with an OLE "link." Accesses (including reading content 
from, and writing content to) to a VDE protected container 
may be passed from an OLE aware application to a VDE 
aware OLE application that accesses protected content in 
conjunction with control information associated with such 
content. 

A VDE aware application may also interact with 
component assemblies within a PPE to allow direct editing of the 
content of a VDE container, whether the content is in a parent or 
embedded VDE content container. This may include the use of a 
VDE aware word processor, for example, to directly edit, (add to, 
delete, or otherwise modify) a VDE container's content. The 



secure VDE processes underlying VDE container content editing 
may be largely or entirely transparent to the editor (user) and 
may transparently enable the editor to securely browse through 
(using a VDE aware application) some or all of the contents of, 
and securely modify one or more of the VDE content containers 
embedded in, a VDE content container hierarchy. 

The embedding processes for all VDE embedded content 
containers normally involves securely identifying the appropriate 
content control information for the embedded content. For 
example, VDE content control information for a VDE installation 
and/or a VDE content container may securely, and transparently 
to an embedder (user), apply the same content control 
information to edited (such as modified or additional) container 
content as is applied to one or more portions (including all, for 
example) of previously "in place" content of said container and/or 
securely apply control information generated through a VDE 
control information negotiation between control sets, and/or it 
may apply control information previously applied to said content. 
Application of control information may occur regardless of 
whether the edited content is in a parent or embedded container. 
This same capability of securely applying content control 
information (which may be automatically and/or transparently 
applied), may also be employed with content that is embedded 
into a VDE container through extracting and embedding content, 



or through the moving, or copying and embedding, of VDE 
container objects. Application of content control information 
normally occurs securely within one or more VDE secure 
sub-system PPEs 650. This process may employ a VDE template 
that enables a user, through easy to use GUI user interface tools, 
to specify VDE content control information for certain or all 
embedded content, and which may include menu driven, user 
selectable and/or definable options, such as picking amongst 
alternative control methods (e.g. between different forms of 
metering) which may be represented by different icons picturing 
(symbolizing) different control functions and apply such functions 
to an increment of VDE secured content, such as an embedded 
object listed on an object directory display. 

Extracting content from a VDE content container, or 
editing or otherwise creating VDE content with a VDE aware 
application, provides content which may be placed within a new 
VDE content container object for embedding into said parent 
VDE container, or such content may be directly placed into a 
previously existing content container. All of these processes may 
be managed by processing VDE content control information 
within one or more VDE installation secure sub-systems. 



VDE content container objects may be embedded in a 
parent object through control information referenced by a parent 



object permissions record that resolves said embedded object's 
location and/or contents. In this case, little or no change to the 
embedded object's previously existing content control information 
may be required. VDE securely managed content which is 
relocated to a certain VDE content container may be relocated 
through the use of VDE sub-system secure processes which may, 
for example, continue to maintain relocated content as encrypted 
or otherwise protected (e.g. by secure tamper resistant barrier 
502) during a relocation/embedding process. 

Embedded content (and/or content objects) may have been 
contributed by different parties and may be integrated into a 
VDE container through a VDE content and content control 
information integration process securely managed through the 
use of one or more secure VDE subsystems. This process may, for 
example, involve one or more of: 

(1.) securely applying instructions controlling the 
embedding and/or use of said submitted content, wherein said 
instructions were securely put in place, at least in part, by a 
content provider and/or user of said VDE container. For 
example, said user and/or provider may interact with one or more 
user interfaces offering a selection of content embedding and/or 
control options (e.g. in the form of a VDE template). Such options 
may include which, and/or whether, one or more controls should 



be applied to one or more portions of said content and/or the 
entry of content control parameter data (such a time period 
before which said content may not be used, cost of use of content, 
and/or pricing discount control parameters such as software 
program suite sale discounting). Once required and/or optional 
content control information is established by a provider and/or 
user, it may function as content control information which may 
be, in part or in full, applied automatically to certain, or all, 
content which is embedded in a VDE content container. 

(2.) secure VDE managed negotiation activities, including 
the use of a user interface interaction between a user at a 
receiving VDE installation and VDE content control information 
associated with the content being submitted for embedding. For 
example, such associated control information may propose 
certain content information and the content receiver may, for 
example, accept, select from a plurality, reject, offer alternative 
control information, and/or apply conditions to the use of certain 
content control information (for example, accept a certain one or 
more controls if said content is used by a certain one or more 
users and/or if the volume of usage of certain content exceeds a 
certain level). 

(3.) a secure, automated, VDE electronic negotiation 
process involving VDE content control information of the 



receiving VDE content container and/or VDE installation and 
content control information associated with the submitted 
content (such as control information in a permissions record of a 
contributed VDE object, certain component assemblies, 
parameter data in one or more UDEs and/or MDEs, etc.). 

Content embedded into a VDE content container may be 
embedded in the form of: 

(1.) content that is directly, securely integrated into 
previously existing content of a VDE content container (said 
container may be a parent or embedded content container) 
without the formation of a new container object. Content control 
information associated with said content after embedding must 
be consistent with any pre*embedding content control 
information controlling, at least in part, the establishment of 
control information required after embedding. Content control 
information for such directly integrated, embedded content may 
be integrated into, and/or otherwise comprise a portion of, control 
information (e.g. in one or more permissions records containing 
content control information) for said VDE container, and/or 

(2.) content that is integrated into said container in one or 
more objects which are nested within said VDE content container 
object. In this instance, control information for said content may 



be carried by either the content control information for the parent 
VDE content container, or it may, for example, be in part or in 
full carried by one or more permissions records contained within 
and/or specifically associated with one or more content containing 
nested VDE objects. Such nesting of VDE content containing 
objects within a parent VDE content container may employ a 
number of levels, that is a VDE content container nested in a 
VDE content container may itself contain one or more nested 
VDE content containers. 

VDE content containers may have a nested structure 
comprising one or more nested containers (objects) that may 
themselves store further containers and/or one or more types of 
content, for example, text, images, audio, and/or any other type of 
electronic information (object content may be specified by content 
control information referencing, for example, byte offset locations 
on storage media). Such content may be stored, communicated, 
and/or used in stream (such as dynamically accumulating and/or 
flowing) and/or static (fixed, such as predefined, complete file) 
form. Such content may be derived by extracting a subset of the 
content of one or more VDE content containers to directly 
produce one or more resulting VDE content containers. VDE 
securely managed content (e.g. through the use of a VDE aware 
ppplication or operating system having extraction capability) 
may be identified for extraction from each of one or more 



locations within one or more VDE content containers and may 
then be securely embedded into a new or existing VDE content 
container through processes executing VDE controls in a secure 
subsystem PPE 650. Such extraction and embedding (VDE 
"exporting") involves securely protecting, including securely 
executing, the VDE exporting processes. 

A VDE activity related to VDE exporting and embedding 
involves performing one or more transformations of VDE content 
from one secure form to one or more other secure forms. Such 
transformation^) may be performed with or without moving 
transformed content to a new VDE content container (e.g. by 
component assemblies operating within a PPE that do not reveal, 
in unprotected form, the results or other output of such 
transforming processes without further VDE processes governing 
use of at least a portion of said content). One example of such a 
transformation process may involve performing mathematical 
transformations and producing results, such as mathematical 
results, while retaining, none, some, or all of the content 
information on which said transformation was performed. Other 
examples of such transformations include converting a document 
format (such as from a WordPerfect format to a Word for 
Windows format, or an SGML document to a Postscript 
document), changing a video format (such as a QuickTime video 
format to a MPEG video format), performing an artificial 



intelligence process (such as analyzing text to produce a 
summary report), and other processing that derives VDE secured 
content from other VDE secured content. 

Figure 79 shows an example of an arrangement of 
commercial VDE users. The users in this example create, 
distribute, redistribute, and use content in a variety of ways. 
This example shows how certain aspects of control information 
associated with content may evolve as control information passes 
through a chain of handling and control. These VDE users and 
controls are explained in more detail below. 

Creator A in this example creates a VDE container and provides 
associated content control information that includes references 
(amongst other things) to several examples of possible "types" of 
VDE control information. In order to help illustrate this 
example, some of the VDE control information passed to another 
VDE participant is grouped into three categories in the following 
more detailed discussion: distribution control information, 
redistribution control information, and usage control information. 
In this example, a fourth category of embedding control 
information can be considered an element of all three of the 
preceding categories. Other groupings of control information are 
. possible (VDE does not require organizing control information in 
this way). The content control information associated with this 



example of a container created by creator A is indicated on 
Figure 80 as C A . Figure 80 further shows the VDE participants 
who may receive enabling control information related to creator 
A's VDE content container. Some of the control information in 
this example is explained in more detail below. 

Some of the distribution control information (in this 
example, control information primarily associated with creation, 
modification, and/or use of control information by distributors) 
specified by creator A includes: (a) distributors will compensate 
creator A for each active user of the content of the container at 
the rate of $10 per user per month, (b) distributors are budgeted 
such that they may allow no more than 100 independent users to 
gain access to such content (i.e. may create no more than 100 
permissions records reflecting content access rights) without 
replenishing this budget, and (c) no distribution rights may be 
passed on in enabling control information (e.g. permissions 
records and associated component assemblies) created for 
distribution to other participants. 

Some of the content redistribution control information (in 
this example, control information produced by a distributor 
within the scope permitted by a more senior participant in a 
chain of handling and control and passed to user/providers (in 
this example, user/distributors) and associated with controls 



and/or other requirements associated with redistribution 
activities by such user/distributors) specified by creator A 
includes: (a) a requirement that control information enabling 
content access may be redistributed by user/distributors no more 
than 2 levels, and further requires that each redistribution 
decrease this value by one, such that a first redistributor is 
restricted to two levels of redistribution, and a second 
redistributor to whom the first redistributor delivers permissions 
will be restricted to one additional level of redistribution, and 
users receiving permissions from the second redistributor will be 
unable to perform further redistribution (such a restriction may 
be enforced, for example, by including as one aspect of a VDE 
control method associated with creating new permissions a 
requirement to invoke one or more methods that: (i) locate the 
current level of redistribution stored, for example, as an integer 
value in a UDE associated with such one or more methods, (ii) 
compare the level of redistribution value to a limiting value, and 
(iii) if such level of redistribution value is less than the limiting 
value, increment such level of redistribution value by one before 
delivering such a UDE to a user as an aspect of content control 
information associated with VDE managed content, or fail the 
process if such value is equal to such a limiting value), and (bj no 
other special restrictions are placed on redistributors. 



Some of the usage control information (in this example, 
control information that a creator requires a distributor to 
provide in control information passed to users and/or 
user/distributors) specified by creator A may include, for 
example: (a) no moves (a form of distribution explained elsewhere 
in this document) of the content are permitted, and (b) 
distributors will be required to preserve (at a minimum) 
sufficient metering information within usage permissions in 
order to calculate the number of users who have accessed the 
container in a month and to prevent further usage after a rental 
has expired (e.g. by using a meter method designed to report 
access usages to creator A through a chain of handling and 
reporting, and/or the use of expiration dates and/or time-aged 
encryption keys within a permissions record or other required 
control information). 

Some of the extracting and/or embedding control 
information specified by creator A in this example may include a 
requirement that no extracting and/or embedding of the content 
is or will be permitted by parties in a chain of handling and 
control associated with this control information, except for users 
who have no redistribution rights related to such VDE secured 
content provided by Creator A. Alternatively, or in addition, as 
regards different portions of said content, control information 
enabling certain extraction and/or embedding may be provided 



along with the redistribution rights described in this example for 
use by user/distributors (who may include user content 
aggregators, that is they may provide content created by, and/or 
received from, different sources so as to create their own content 
products). 

Distributor A in this example has selected a basic approach 
that distributor A prefers when offering enabling content control 
information to users and/or user/distributors that favors rental of 
content access rights over other approaches. In this example, 
some of the control information provided by creators will permit 
distributor A to fulfill this favored approach directly, and other 
control structures may disallow this favored approach (unless, for 
example, distributor A completes a successful VDE negotiation 
allowing such an approach and supporting appropriate control 
information). Many of the control structures received by 
distributor A, in this example, are derived from (and reflect the 
results of) a VDE negotiation process in which distributor A 
indicates a preference for distribution control information that 
authorizes the creation of usage control information reflecting 
rental based usage rights. Such distribution control information 
may allow distributor A to introduce and/or modify control 
structures provided by creators in such a way as to create control 
information for distribution to users and/or user/distributors 
that, in effect, rent* access rights. Furthermore, distributor A in 



this example services requests from user/distributors for 
redistribution rights, and therefore also favors distribution 
control information negotiated (or otherwise agreed to) with 
creators that permits distributor A to include such rights as an 
aspect of control information produced by distributor A. 

In this example, distributor A and creator A may use VDE 
to negotiate (for example, VDE negotiate) for a distribution 
relationship. Since in this example creator A has produced a 
VDE content container and associated control information that 
indicates creator A's desire to receive compensation based on 
rental of usage rights, and such control information further 
indicates that creator A has placed acceptable restrictions in 
redistribution control information that distributor A may use to 
service requests from user/distributors, distributor A may accept 
creator A's distribution control information without any 
negotiated changes. 

After receiving enabling distribution control information 
from creator A, distributor A may manipulate an application 
program to specify some or all of the particulars of usage control 
information for users and/or user/distributors enabled by 
distributor A (as allowed, or not prevented, by senior control 
information). Distributor A may, for example, determine that a 
price of $15 per month per user would meet distributor A's 
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business objectives with respect to payments from users for 
creator A's container. Distributor A must specify usage control 
information that fulfill the requirements of the distribution 
control information given to distributor A by creator A. For 
example, distributor A may include any required expiration dates 
and/or time-aged encryption keys in the specification of control 
information in accordance with creator A's requirements. If 
distributor A failed to include such information (or to meet other 
requirements) in their specification of control information, the 
control method(s) referenced in creator A's permissions record 
and securely invoked within a PPE 650 to actually create this 
control information would, in this example, fail to execute in the 
desired way (e.g. based on checks of proposed values in certain 
fields, a requirement that certain methods be included in 
permissions, etc.) until acceptable information were included in 
distributor A's control information specification. 

In this example, user A may have established an account 
with distributor A such that user A may receive VDE managed 
content usage control information from distributor A. User A 
may receive content usage control information from distributor A 
to access and use creator As content. Since the usage control 
information has passed through (and been added to, and/or 
modified by) a chain of handling including distributor A, the 
usage control information requested from distributor A to make 
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of creator A's content will, in this example, reflect a composite 
of control information from creator A and distributor A. For 
example, creator A may have established a meter method that 
will generate an audit record if a user accesses creator A's VDE 
controlled content container if the user has not previously 
accessed the container within the same calendar month (e.g. by 
storing the date of the user's last access in a UDE associated with 
an open container event referenced in a method core of such a 
meter method and comparing such a date upon subsequent 
access to determine if such access has occurred within the same 
calendar month). Distributor A may make use of such a meter 
method in a control method (e.g. also created and/or provided by 
creator A, or created and/or provided by distributor A) associated 
with opening creator A's container that invokes one or more 
billing and/or budget methods created, modified, referenced in 
one or more permissions records and/or parameterized by 
distributor A to reflect a charge for monthly usage as described 
above. If distributor A has specified usage and/or redistribution 
control information within the boundaries permitted by creator 
A's senior control information, a new set of control information 
(shown as D A (C A ) in Figure 80) may be associated with creator 
A's VDE content container when control information associated 
with that container by distributor A are delivered to users and/or 
user/distributors (user A, user B, and user/distributor A in this 
example). 



In this example, user A may receive control information 
related to creator A's VDE content container from distributor A. 
This control information may represent an extended agreement 
between user A and distributor A (e.g. regarding fees associated 
with use of content, limited redistribution rights, etc.) and 
distributor A and creator A (e.g. regarding the character, extent, 
handling, reporting, and/or other aspects of the use and/or 
creation of VDE controlled content usage information and/or 
content control information received, for example, by distributor 
A from creator A, or vice versa, or in other VDE content usage 
information handling). Such an extended agreement is enforced 
by processes operating within a secure subsystem of each 
participant's VDE installation. The portion of such an extended 
agreement representing control information of creator A as 
modified by distributor A in this example is represented by 
D A (C A ), including, for example, (a) control structures (e.g. one or 
more component assemblies, one or more permissions records, 
etc.), (b) the recording of usage information generated in the 
course of using creator A's content in conformance with 
requirements stated in such control information, (c) making 
payments (including automatic electronic credit and/or currency 
payments "executed" in response to such usage) as a consequence 
of such usage (wherein such consequences may also include 
electronically, securely and automatically receiving a bill 
delivered through use of VDE, wherein such a bill is derived from 



said usage), (d) other actions by user A and/or a VDE secure 
subsystem at user A's VDE installation that are a consequence of 
such usage and/or such control information. 

In addition to control information D A (C A ), user A may 
enforce her own control information on her usage of creator A's 
VDE content container (within the limits of senior content control 
information). This control information may include, for example, 
(a) transaction, session, time based, and/or other thresholds 
placed on usage such that if such thresholds (e.g. quantity limits, 
for example, self imposed limits on the amount of expenditure per 
activity parameter) are exceeded user A must give explicit 
approval before continuing, (b) privacy requirements of user A 
with respect to the recording and/or transmission of certain usage 
related details relating to user As usage of creator A's content, (c) 
backup requirements that user A places on herself in order to 
help ensure a preservation of value remaining in creator A's 
content container and/or local store of electronic credit and/or 
currency that might otherwise be lost due to system failure or 
other causes. The right to perform in some or all of these 
examples of user A's control information, in some examples, may 
be negotiated with distributor A. Other such user specified 
control information may be enforced independent of any control 
information received from any content provider and may be set in 
relationship to a user's, or more generally, a VDE installation's, 
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control information for one or more classes, or for all classes, of 
content and/or electronic appliance usage. The entire set of VDE 
control information that may be in place during user A's usage of 
creator A's content container is referred to on Figure 80 as 
U (D (CJ). This set may represent the control information 

AAA 

originated by creator A, as modified by distributor A, as further 
modified by user A, all in accordance with control information 
from value chain parties providing more senior control 
information, and therefore constitutes, for this example, a 
'complete" VDE extended agreement between user A, distributor 
A, and creator A regarding creator A's VDE content container. 
User B may, for example, also receive such control information 

D (C ) from distributor A, and add her own control information 

A A 

in authorized ways to form the set U B (D A (C A )). 

User/distributor A may also receive VDE control 
information from distributor A related to creator A's VDE content 
container. User/distributor A may, for example, both use creator 
A's content as a user and act as a redistributor of control 
information- In this example, control information D A (C A ) both 
enables and limits these two activities. To the extent permitted 
by D A (C A ), user/distributor A may create their own control 

A A 

information based on D A (C A ) UD A (D A (C A )) - that controls both 
user/distributor A's usage (in a manner similar to that described 
above in connection with user A and user B), and control 



information redistributed by user/distributor A (in a manner 
similar to that described above in connection with distributor A). 
For example, if user/distributor A redistributes UD A (D A (C A )) to 
user/distributor B, user/distributor B may be required to report 
certain usage information to user/distributor A that was not 
required by either creator A or distributor A. Alternatively or in 
addition, user/distributor B may, for example, agree to pay 
user/distributor A a fee to use creator A's content based on the 
number of minutes user/distributor B uses creator A's content 
(rather than the monthly fee charged to user/distributor A by 
distributor A for user/distributor B's usage). 

In this example, user/distributor A may distribute control 
information ^ A (D A iC A )) to ^er/distributor B that permits 
user/distributor B to further redistribute control information 
associated with creator A's content. User/distributor B may 
make a new set of control information in) B (UD A (D A (C A ))). If the 
control information UD A (D A (C A )) P ermits user/distributor B to 
redistribute, the restrictions on redistribution from creator A in 
this example will prohibit the set UD B (UD A (D A (C A ))) from 
including further redistribution rights (e.g. providing 
redistribution rights to user B) because the chain of handling 
from distributor A to user/distributor A (distribution) and the 
continuation of that chain from user/distributor A to 
user/distributor B (first level of redistribution) and the further 



continuation of that chain to another user represents two levels 
of redistribution, and, therefore, a set UD B (UD A (D A (C A ))) may 
not, in this example, include further redistribution rights. 

As indicated in Figure 79, user B may employ content from 
both user/distributor B and distributor A (amongst others). In 
this example, as illustrated in Figure 80, user B may receive 
control information associated with creator A's content from 
distributor A and/or user/distributor B. In either case, user B 
may be able to establish their own control information on D A (C A ) 
and/or UD B (UD A (D A (C A ))), respectively (if allowed by such 
control information. The resulting set(s) of control information, 
U B (D A (C A )) and/or U B (UD B (UD A (D A (C A )))) respectively, may 
represent different control scenarios, each of which may have 
benefits for user B. As described in connection with an earlier 
example, user B may have received control information from 
user/distributor B along a chain of handling including 
user/distributor A that bases fees on the number of minutes that 
user B makes use of creator A's content (and requiring 
user/distributor A to pay fees of $15 per month per user to 
distributor A regardless of the amount of usage by user B in a 
calendar month). This may be more favorable under some 
circumstances than the fees required by a direct use of control 
information provided by distributor A, but may also have the 
disadvantage of an exhausted chain of redistribution and, for 



example, further usage information reporting requirements 
included in UD B (UD A (D A (C A ))). If the two sets of control 
information D A (C A ) and UD B (UD A (D A (C A ))) permit (e.g. do not 
require exclusivity enforced, for example, by using a registration 
interval in an object registry used by a secure subsystem of user 
B's VDE installation to prevent deregistration and reregistration 
of different sets of control information related to a certain 
container (or registration of plural copies of the same content 
having different control information and/or being supplied by 
different content providers) within a particular interval of time as 
an aspect of an extended agreement for a chain of handling and 
control reflected in D A (C A ) and/or UD B (UD A (D A (C A ))) ), user B 
may have both sets of control information registered and may 
make use of the set that they find preferable under a given usage 
scenario. 

In this example, creator B creates a VDE content container 
and associates a set of VDE control information with such 
container indicated in Figure 81 as C B . Figure 81 further shows 
the VDE participants who may receive enabling control 
information related to creator B's VDE content container. In this 
example, control information may indicate that distributors of 
creator B's content: (a) must pay creator B $0.50 per kilobyte of 
. information decrypted by users and/or user/distributors 
authorized by such a distributor, (b) may allow users and/or 



user/distributors to embed their content container in another 
container while maintaining a requirement that creator B receive 
$0.50 per kilobyte of content decrypted, (c) have no restrictions on 
the number of enabling control information sets that may be 
generated for users and/or user/distributors, (d) must report 
information concerning the number of such distributed control 
information sets at certain time intervals (e.g. at least once per 
month), (e) may create control information that allows users 
and/or user/distributors to perform up to three moves of their 
control information, (f) may allow redistribution of control 
information by user/distributors up to three levels of 
redistribution, (g) may allow up to one move per user receiving 
redistributed control information from a user/distributor. 

In this example, distributor A may request control 
information from creator B that enables distributor A to 
distribute control information to users and/or user/distributors 
that is associated with the VDE container described above in 
connection with creator B. As stated earlier, distributor A has 
established a business model that favors "rental" of access rights 
to users and user/distributors receiving such rights from 
distributor A. Creator B's distribution control information in this 
example does not force a model including "rental" of rights, but 
rather bases payment amounts on the quantity of content 
decrypted by a user or user/distributor. In this example, 
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distributor A may use VDE to negotiate with creator B to include 
a different usage information recording model allowed by creator 
B. This model may be based on including one or more meter 
methods in control structures associated with creator B's 
container that will record the number of bytes decrypted by end 
users, but not charge users a fee based on such decryptions; 
rather distributor A proposes, and creator B's control information 
agrees to allow, a "rental" model to charge users, and determines 
the amount of payments to creator B based on information 
recorded by the bytes decrypted meter methods and/or collections 
of payment from users. 

Creator B may, for example, (a) accept such a new control 
model with distributor A acting as the auditor (e.g. trusting a 
control method associated with processing audit information 
received by distributor A from users of creator B's content using a 
VDE secure subsystem at distributor A's site, and further to 
securely calculate amounts owed by distributor A to creator B 
and, for example, making payments to creator B using a 
mutually acceptable budget method managing payments to 
creator B from credit and/or currency held by distributor A), (b) 
accept such a new control model based on distributor A's 
eptance of a third party to perform all audit functions 
ociated with this content, (c) may accept such a model if 
information associated with the one or more meter methods that 
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record the number of bytes decrypted by users is securely 
packaged by distributor B's VDE secure subsystem and is 
securely, employing VDE communications techniques, sent to 
creator B in addition to distributor A, and/or (d) other mutually 
acceptable conditions. Control information produced by 
distributor A based on modifications performed by distributor A 
as permitted by C B are referred to in this example as D A (C B ). 

User A may receive a set of control information D A (C B ) 
from distributor A. As indicated above in connection with 
content received from creator A via a chain of handling including 
distributor A, user A may apply their own control information to 
the control information D A (C fi ), to the extent permitted by 
D A (C B ), to produce a set of control information U A (D A (C B )). The 
set of control information D A (C B ) may include one or more meter 
methods that record the number of bytes of content from creator 
B's container decrypted by user A (in order to allow correct 
calculation of amounts owed by distributor A to creator B for user 
A's usage of creator B's content in accordance with the control 
information of C B that requires payment of $0.50 per kilobyte of 
decrypted information), and a further meter method associated 
with recording usage such that distributor A may gather 
sufficient information to securely generate billings associated 
with user A's usage of creator B's content and based on a "rental" 
model (e.g. distributor A may, for example, have included a meter 
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method that records each calendar month that user A makes use 
of creator B's content, and relates to further control information 
that charges user A $10 per month for each such month during 
which user A makes use of such content.) 

User/distributor A may receive control information C B 
directly from creator B. In this case, creator B may use VDE to 
negotiate with user/distributor A and deliver a set of control 
information C B that may be the same or differ from that 
described above in connection with the distribution relationship 
established between creator B and distributor A. For example, 
user/distributor A may receive control information C B that 
includes a requirement that user/distributor A pay creator B for 
content decrypted by user/distributor A (and any participant 
receiving distributed and/or redistributed control information 
from user/distributor A) atthe rate of $0.50per kilobyte. As 
indicated above, user/distributor A also may receive control 
information associated with creator B's VDE content container 
from distributor A. In this example, user/distributor A may have 
a choice between paying a "rental" fee through a chain of 
handling passing through distributor A, and a fee based on the 
quantity of decryption through a chain of handling direct to 
creator B. In this case, user/distributor A may have the ability to 
choose to use either or both of C B and D A (C B ). As indicated 
earlier in connection with a chain of handling including creator A 



and distributor A, user/distributor A may apply her own control 
information to the extent permitted by C B and/or D A (C B ) to form 
the sets of control information UD A (C B ) and UD A (D A (C B )), 
respectively. 

As illustrated in Figure 81, in this example, user B may 
receive control information associated with creator B's VDE 
content container from six different sources: C B directly from 
creator B, D A (C B ) from distributor A, UD B (UD A (D A (C B ))) and/or 
UD B (TJD A (C B » from user/distributor B, D C (C B ) from distributor 
C, and/or D B (D C (C B )) from distributor B. This represents six 
chains of handling through which user B may enter into extended 
agreements with other participants in this example. Two of these 
chains pass through user/distributor B. Based on a VDE 
negotiation between user/distributor B and user B, an extended 
agreement may be reached (if permitted by control information 
governing both parties) that reflects the conditions under which 
user B may use one or both sets of control information. In this 
example, two chains of handling and control may "converge" at 
user/distributor B, and then pass to user B (and if control 
information permits, later diverge once again based on 
distribution and/or redistribution by user B). 

In this example, creator C produces one or more sets of 
control information C r associated with a VDE content container 
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created by creator C, as shown in Figure 82. Figure 82 farther 
shows the VDE participants who may receive enabling control 
information related to creator C's VDE content container. The 
content in such a container is, in this example, organized into a 
set of text articles. In this example control information may 
include one or more component assemblies that describe the 
articles within such a container (e.g. one or more event methods 
referencing map tables and/or algorithms that describe the extent 
of each article). C c may further include, for example: (a) a 
requirement that distributors ensure that creator C receive $1 
per article accessed by users and/or user/distributors, which 
payment allows a user to access such an article for a period of no 
more than six months (e.g. using a map-type meter method that 
is aged once per month, time aged decryption keys, expiration 
dates associated with relevant permissions records, etc.), (b) 
control information that allows articles from creator C's container 
to be extracted and embedded into another container for a one 
time charge per extract/embed of $10, (c) prohibits 
extracted/embedded articles from being reextracted, (d) permits 
distributors to create enabling control information for up to 1000 
users or user/distributors per month, (e) requires that 
information regarding the number of users and user/distributors 
enabled by a distributor be reported to creator C at least once per 
week, (f) permits distributors to enable users or user/distributors 



to perform up to one move of enabling control information, and 
(g) permits up to 2 levels of redistribution by user/distributors. 

In this example, distributor B may establish a distribution 
relationship with creator C. Distributor B in this example may 
have established a business model that favors the distribution of 
control information to users and user/distributors that bases 
payments to distributor B based on the number of accesses 
performed by such VDE participants. In this example, 
distributor B may create a modified set D B (C C ) of enabling 
control information for distribution to users and/or 
user/distributors. This set Dg(C c ) may, for example, be based on 
a negotiation using VDE to establish a fee of $0.10 per access per 
user for users and/or user/distributors who receive control 
information from distributor B. For example, if one or more 
map-type meter methods have been included in C c to ensure that 
adequate information may be gathered from users and/or 
user/distributors to ensure correct payments to creator C by 
distributor B based on C c , such methods may be preserved in the 
set D B (C C ), and one or more further meter methods (and any 
other necessary control structures such as billing and/or budget 
methods) may be included to record each access such that the set 
D B (C C ) will also ensure that distributor B will receive payments 
based on each access. 



The client administrator in this example may receive a set 
of content control information D B (C C ) that differs, for example, 
from control information received by user B from distributor B. 
For example, the client administrator may use VDE to negotiate 
with distributor B to establish a set of control information for 
content from all creators for whom distributor B may provide 
enabling content control information to the client administrator. 
For example, the client administrator may receive a set of control 
information D B (C C ) that reflects the results of a VDE negotiation 
between the client administrator and distributor B. The client 
administrator may include a set of modifications to D B (C C ) and 
form a new set CA(D B (C C )) that includes control information that 
may only be available to users and user/distributors within the 
same organization as the client administrator (e.g. coworkers, 
employees, consultants, etc.) In order to enforce such an 
arrangement, CA(D B (C C )) may, for example, include control 
structures that examine name services information associated 
with a user or user/distributor during registration, establish a 
new budget method administered by the client administrator and 
required for use of the content, etc. 

A distributor may provide redistribution rights to a client 
administrator which allows said administrator to redistribute 
rights to create permissions records for certain content 
(redistribute rights to use said content) only within the 



and/or user/distributors to no more than one, (e) a requirement 
that distributors limit user/distributors to no more than four 
levels of redistribution, and (f) that distributors may create 
enabling control information that permits other distributors to 
create control information as distributors, but may not pass this 
capability to such enabled distributors, and further requires that 
audit information associated with use of control information by 
such enabled distributors shall pass directly to creator D without 
processing by such enabling distributor and that creator D shall 
pay such an enabling distributor 10% of any payments received 
by creator D from such an enabled distributor. 

In this example, distributor C may receive VDE content 
containers from creator B, creator C, and creator D, and 
associated sets of control information C fi , C c , and C D . 
Distributor C may use the embedding control information and 
other control information to produce a new container with two or 
more VDE objects received from creator B, creator C, and creator 
D. In addition or alternatively, distributor C may create enabling 
control information for distribution to users and/or 
user/distributors (or in the case of C D , for distributors) for such 
received containers individually. For example, distributor C may 
create a container including content portions (e.g. embedded 
containers) from creator B, creator C, and creator D in which 
each such portion has control information related to its access 



administrator has adequate control information (e.g. control 
information distributed to user/distributor C that allows 
redistribution to users such as user D) to help ensure that control 
information flows through the client administrator's organization 
in accordance with policies, procedures, and/or other 
administrative processes. 

In this example, user E may receive control information 
from the client administrator and/or distributor B. For example, 
user E may have an account with distributor B even though some 
control information may be received from the client 
administrator. In this case, user E may be permitted to request 
and receive control information from distributor B without 
restriction, or the client administrator may have, as a matter of 
organizational policy, control information in place associated with 
user E's electronic appliance that limits the scope of user E's 
interaction with distributor B. In the latter case, the client 
administrator may, for example, have limited user E to 
registering control information with the secure subsystem of user 
E's electronic appliance that is not available from the client 
administrator, is from one or more certain classes of distributors 
and/or creators, and/or has a cost for usage, such as a certain 
price point (e.g. $50 per hour of usage). Alternatively or in 
addition, the client administrator may, for example, limit user E 
to receiving control information from distributor B in which user 



administrator's organization and to no other parties. Similarly, 
such administrator may extend such a "limited" right to 
redistribute to department and/or other ao^ministrator within his 
organization such that they may redistribute such rights to use 
content based on one or more restricted lists of individuals and/or 
classes and/or other groupings of organization personnel as 
defined by said adnunistrator. This VDE capability to limit 
redistribution to certain one or more parties and/or classes and/or 
other groupings of VDE users and/or installations can be applied 
to content by any VDE content provider, so long as such a control 
is allowed by senior control information. 

User D in this example may receive control information 
from either the client ao^ministrator and/or user/distributor C. 
User/distributor C may, for example, distribute control 
information UD C (CA(D B (C C ))) to user D that includes a 
departmental budget method managed by user/distributor C to 
allow user/distributor C to maintain an additional level of control 
over the actions of user D. In this case, UD C (CA(D B (C C ))) may 
include multiple levels of organizational controls (e.g. controls 
originating with the client administrator and further controls 
originating with user/distributor C) in addition to controls 
resulting from a commercial distribution channel. In addition or 
alternatively, the client administrator may refuse to distribute 
certain classes of control information to user D even if the client 



E receives a more favorable price (or other control information 
criteria) than the price (or other criteria) available in control 
information from the client administrator. 

In this example, creator D may create a VDE content 
container that is designed primarily for integration with other 
content (e.g. through use of a VDE extracting/embedding 
process), for example, content provided by creator B and creator 
C. Figure 83 shows the VDE participants who may receive 
enabling control information related a VDE content container 
produced by creator D. Control information associated with 
creator D's content (C D in Figure 83) may include, for example: 
(a) a requirement that distributors make payment of either $1.50 
per open per user, or $25 per user for an unlimited number of 
opens, (b) a discount of 20% for any user that has previously paid 
for an unlimited number of opens for certain other content 
created by creator D (e.g. implemented by including one or more 
billing methods that analyze a secure database of a user's VDE 
installation to determine if any of such certain other containers 
are registered, and further determines the character of rights 
held by a user purchasing rights to this container), (c) a 
requirement that distributors report the number of users and 
user/distributors enabled by control information produced in 
accordance with C D after such number exceeds 1000, (d) a 
requirement that distributors limit the number of moves by users 



and use that records, and allows an auditor to gather, sufficient 
information for each such creator to securely and reliably receive 
payments from distributor C based on usage activities related to 
users and/or user/distributors enabled by distributor C. 
Furthermore, distributor C may negotiate using VDE with some 
or all of such creators to enable a model in which distributor C 
provides overall control information for the entire container 
based on a "uniform" fee (e.g. calculated per month, per access, 
from a combined model, etc.) charged to users and/or 
user/distributors, while preserving the models of each such 
creator with respect to payments due to them by distributor C 
based on C B , C c , and/or C D , and, for example, resulting from 
each of their differing models for the collection of content usage 
information and any related (e.g. advertising) information. 

In this example, distributor B may receive a VDE content 
container and associated content control information C £ from 
creator E as shown in Figure 83. If C £ permits, distributor B 
may extract a portion of the content in such a container. 
Distributor B may then, for example, embed this portion in a 
container received from distributor C that contains an 
aggregation of VDE objects created by creator B, creator C, and 
creator D. Depending on the particular restrictions and/or 
permissions in the sets of control information received from each 
creator and distributor C, distributor B may, for example, be able 
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to embed such an extracted portion into the container received 
from distributor C as an independent VDE object, or directly into 
content of "in place" objects from creator B, creator C, and/or 
creator D. Alternatively, or in addition, distributor B may, if 
permitted by C E , choose to distribute such an extracted portion of 
content as an independent VDE object. 

User B may, in this example, receive a VDE content 
container from distributor C that is comprised of VDE objects 
created by creator B, creator C, and creator D. In addition, user 
B may receive a VDE content container from distributor B that 
contains the same content created by creator B, creator C, and 
creator D in addition to one or more extracted/embedded portions 
of content created by creator E. User B may base decisions 
concerning which of such containers they choose to use (including 
which embedded containers she may wish to use), and under 
which circumstances, based on, for example, the character of such 
extracted/embedded portions (e.g. multimedia presentations 
illustrating potential areas of interest in the remainder of the 
content, commentary explaining and/or expositing other elements 
of content, related works, improved application software 
delivered as an element of content, etc.); the quality, utility, 
and/or price (or other attributes of control information) of such 
portions; and other considerations which distinguish the 



containers and/or content control information received, in this 
example, from distributor B and distributor C. 

User B may receive content control information from 
distributor B for such a VDE content container that permits user 
B to add and/or modify content contained therein. User B may, 
for example, desire an ability to annotate content in such a 
container using a VDE aware word processor or other 
application^). If permitted by senior control information, some 
or all of the content may be available to user B for modification 
and/or additions. In this case, user B is acting as a VDE creator 
for added and/or modified content. User B may, for example, 
provide new control information for such content, or may be 
required (or desire to) make use of existing control information 
(or control information included by senior members of a chain of 
handling for this purpose) to manage such content (based on 
control information related to such a container and/or contained 
objects). 

In this example, VDE 100 has been used to enable an 
environment including, for example, content distribution, 
redistribution, aggregation (extracting and/or embedding), 
reaggregation, modification, and usage. The environment in this 
. example allows competitive models in which both control 
information and content may be negotiated for and have different 



particulars based on the chain of handling through which coi 
information and/or content has been passed. Furthermore, t 
environment in this example permits content to be added to, 
and/or modified by, VDE participants receiving control 
information that enables such activities. 



Example - Content Distribution Through a Content VDE Chain 
of Handling 

Figure 84 reflects certain aspects of a relatively simple 
model 3400 of VDE content distribution involving several 
categories of VDE participants. In this instance, and for 
simplicity of reference purposes, various portions of content are 
represented as discrete items in the form of VDE content 
container objects. One or more of such content portions may also 
be integrated together in a single object and may (as may the 
contents of any VDE content container object if allowed by 
content control information) be extracted in whole or part by a 
user. In this example, publishers of historical/educational 
multimedia content have created VDE content containers 
through the use of content objects available from three content 
resources: 

• a Video Library 3402 product available to Publishers on 
optical discs and containing video clip VDE objects 
representing various historical situations, 

• an Internet Repository 3404 which stores history 
information text and picture resources in VDE objects 
which are available for downloading to Publishers and 
other users, and 



• an Audio Libraiy 3406, also available on optical discs, and 
containing various pieces of musical performances and 
vocal performances (for example, historical narrations) 
which can be used alone or to accompany other educational 
historical materials. 

The information provided in library 3402, repository 3404, and 
library 3406 may be provided to different publishers 3408(a), 
3408(b), .... 3408(n). Publishers 3408 may, in turn, provide some 
or all of the information they obtain to end users 3410. 

In this example, the Video Library 3402 control 
information allows publishers to extract objects from the Video 
Library product container and content control information 
enabling use of each extracted object during a calendar year if 
the object has a license cost of $50 or less, and is shorter than 45 
minutes in duration, and 20,000 copies of each of any other 
extracted objects, and further requires all video objects to be VDE 
fingerprinted upon decryption. The Audio Library 3404 has 
established similar controls that match its business model. The 
Internet Repository 3406 VDE containerizes, including encrypts, 
selected object content as it streams out of the Repository in 
response to an online, user request to download an object. The 
Repository 3406 may fingerprint the identification of the 
receiving VDE installation into its content prior to encryption 



and communication to a publisher, and may further require user 
identification fingerprinting of their content when decrypted by 
said Publisher or other content user. 

The Publishers 3408 in this example have selected, under 
terms and conditions VDE negotiated (or otherwise agreed to) 
with the providing resources, various content pieces which they 
combine together to form their VDE object container products for 
their teacher customers. Publisher 3408(A) has combined video 
objects extracted from the Video Library 3402 (as indicated by 
circles), text and image objects extracted from the Internet 
Repository 3404 (indicated by diamonds), and one musical piece 
and one historical narration extracted from the Audio Library 
3406 (as indicated by rectangles). Publisher 3408(B) has 
extracted a similar array of objects to be combined into his 
product, and has further added graphical elements (indicated by 
a hexagon) created by Publisher 3408(B) to enhance the product. 
Publisher 3408(C) has also created a product by combining 
objects from the Internet Repository 3404 and the Audio Library 
3406. In this example, all publisher products are delivered, on 
their respective optical discs, in the form of VDE content 
container objects with embedded objects, to a modern high school 
for installation on the high school's computer network. 



In this particular example, End-Users 3410 are teachers 
who vise their VDE node's secure subsystems to access the VDE 
installation on their high school server that supports the 
publishers' products (in an alternative example, the high school 
may maintain only a server based VDE installation). These 
teachers license the VDE products from one or more of the 
publishers and extract desired objects from the VDE product 
content containers and either download the extracted VDE 
content in the form of VDE content containers for storage on 
their classroom computers and/or as appropriate and/or efficient. 
The teachers may store extracted content in the form of VDE 
content containers on server mass storage (and/or if desired and 
available to an end-user, and further according to acceptable 
pricing and/or other terms and conditions and/or senior content 
control information, they may store extracted information in 
"clear* unencrypted form on their nodes' and/or server storage 
means). This allows the teachers to play, and/or otherwise use, 
the selected portions of said publishers' products, and as shown 
in two instances in this example, add further teacher and/or 
student created content to said objects. End-user 3410(2), for 
example, has selected a video piece 1 received from Publisher A, 
who received said object from the Video Library. End-user 
3410(3) has also received a video piece 3 from the same Publisher 
3408(A) wherein said piece was also available to her from 
Publisher 3408(B), but perhaps under not as favorable terms and 



conditions (such as a support consultation telephone line). In 
addition, end-user 3410(3) has received an audio historical 
narration from Publisher 3408(B) which corresponds to the 
content of historical reference piece 7. End-user 3410(3) has also 
received a corresponding historical reference piece 7 (a book) 
from publisher 3408(2) who received said book from the Internet 
Repository 3404. In this instance, perhaps publisher 3408(2) 
charged less for said book because end-user 3410(3) has also 
licensed historical reference piece 7 from him, rather than 
publisher 3408(1), who also carried the same book. End-user 
3410(3), as a teacher, has selected the items she considers most 
appropriate for her classes and, through use of VDE, has been 
able to flexibly extract such items from resources available to her 
(in this instance, extracting objects from various optical products 
provided by publishers and available on the local high school 
network server). 
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Example - Diutribution of Content Control Information Within 
an Organization 

Figure 85 shows two VDE content containers, Container 
300(A) and Container 300(B), that have been distributed to a 
VDE Client Administrator 3450 in a large organization. As 
shown in the figure, Container 300(A) and Container 300(B), as 
they arrive at the corporation, carry certain control information 
specifying available usage rights for the organization. As can be 
farther seen in Figure 85, the client administrator 3450 has 
distributed certain subsets of these rights to certain department 
administrators 3452 of her organization, such as Sales and 
Marketing Administrator 3452(1), Planning Administrator 
3452(2), and Research and Development Administrator 3452(k). 
In each instance, the Client Administrator 3450 has decided 
which usage options and how much budget should be made 
available to each department. 

Figure 85 is a simplified example and, for example, the 
Client Administrator 3450 could have added further VDE 
controls created by herself and/or modified and/or deleted in place 
controls (if allowed by senior content control information; and/or 
(if allowed by control information) she could have further divided 
the available monetary budget (or other budgets) among specific 
usage activities. In this example, departmental administrators 
have the same rights to determine the rights of departmental 



end-users as the client administrator has in regard to 
departments. In addition, in this example (but not shown in 
Figure 85) the client administrator 3450 and/or content 
providers) may also determine certain control information which 
must directly control (including providing rights related to) end- 
user content usage and/or the consequences of said usage for all 
or certain classes of end-users. In the example shown in Figure 
85, there are only three levels of VDE participants within the 
organization: 

a Client Administrator 3450, 
department administrators 3452, and 
end-users 3454. 
In other examples, VDE will support many levels of VDE 
administration (including overlapping groups) within an 
organization (e.g., division, department, project, network, group, 
end-users, etc). In addition, administrators in a VDE model may 
also themselves be VDE content users. 

Within an organization, VDE installations may be at each 
end-user 3454 node, only on servers or other multiple user 
computers or other electronic appliances, or there may be a mixed 
environment. Determination as to the mix of VDE server and/or 
node usage may be based on organization and/or content provider 
security, performance, cost overhead, or other considerations. 



In this example, communications between VDE 
participants in Figure 85 employs VDE secure communication 
techniques between VDE secure subsystems supporting PPEs 
and other VDE secure system components at each VDE 
installation within the organization. 



Example - Another Content Distribution Example 

Creators of VDE protected content may interact with other 
VDE participants in many different ways. A VDE creator 102 
may, for example, distribute content and/or content control 
information directly to users, distribute content and/or content 
control information to commercial content repositories, distribute 
content and/or content control information to corporate content 
repositories, and/or distribute content and/or content control 
information to other VDE participants. If a creator 102 does not 
interact directly with all users of her content, she may transmit 
distribution permissions to other VDE participants that permit 
such participants to further distribute content and/or content 
control information. She may also allow further distribution of 
VDE content and/or content control information by, for example, 
not restricting redistribution of control information, or allowing a 
VDE participant to act as a "conduit" for one or more permissions 
records that can be passed along to another party, wherein said 
permissions record provides for including the identification of the 
first receiving party and/or the second receiving party. 

Figure 86 shows one possible arrangement of VDE 
participants. In this example, creator 102 may employ one or 
more application software programs and one or more VDE secure 
subsystems to place unencrypted content into VDE protected 



form (i.e., into one or more VDE content containers). In addition, 
creator 102 may produce one or more distribution permissions 
3502 and/or usage permissions 3500 as an aspect of control 
information associated with such VDE protected content. Such 
distribution and/or usage permissions 3500, 3502 may be the 
same (e.g., all distribution permissions may have substantively 
all the same characteristics), or they may differ based on the 
category and/or class of participant for whom they are produced, 
the circumstances under which they are requested and/or 
transmitted, changing content control models of either creator 
102 or a recipient, etc. 

In this example, creator 102 transmits (e.g., over a 
network, via broadcast, and/or through transfer of physical 
media) VDE protected content to user 112a, user 112b, and/or 
user 112c. In addition, creator 102 transmits, using VDE secure 
communications techniques, usage permissions to such users. 
User 112a, user 112b, and user 112c may use such VDE 
protected content within the restrictions of control information 
specified by usage permissions received from creator 102. In this 
case, creator 102 may, for example, manage all aspects of such 
users activities related to VDE protected content transmitted to 
them by creator 102. Alternatively, creator 102 may, for 
example, include references to control information that must be 



available to users that is not provided by creator 102 (e.g., 
component assemblies managed by another party). 

Commercial content repository 200g, in this example, may 
receive VDE protected (or otherwise securely delivered) content 
and distribution, permissions and/or other content usage control 
information from creator 102. Commercial content repository 
200g may store content securely such that users may obtain such, 
when any required conditions are met, content from the 
repository 200g. The distribution permissions 3502 may, for 
example, permit commercial content repository 200g to create 
redistribution permissions and/or usage permissions 3500, 3502 
using a VDE protected subsystem within certain restrictions 
described in content control information received from creator 
102 (e.g., not to exceed a certain number of copies, requiring 
certain payments by commercial content repository 200g to 
creator 102, requiring recipients of such permissions to meet 
certain reporting requirements related to content usage 
information, etc.). Such content control information may be 
stored at the repository installation and be applied to 
unencrypted content as it is transmitted from said repository in 
response to a user request, wherein said content is placed into a 
VDE container as a step in a secure process of communicating 
such content to a user. Redistribution permissions may, for 
example, permit a recipient of such permissions to create a 



certain number of usage permissions within certain restrictions 
(e.g., only to members of the same household, business other 
organization, etc.). Repository 200g may, for example, be 
required by control information received from creator 102 to 
gather and report content usage information from all VDE 
participants to whom the repository has distributed permissions. 

In this example, power user 112d may receive VDE 
protected content and redistribution permissions from 
commercial content repository 200g using the desktop computer 
3504. Power user 112d may, for example, then use application 
software in conjunction with a VDE secure subsystem of such 
desktop computer 3504 in order to produce usage permissions for 
the desktop computer 3504, laptop computer 3506 and/or settop 
appliance 3508 (assuming redistribution permissions received 
from commercial content repository 200g permit such activities). 
If permitted by senior control information (for example, from 
creator 102 as may be modified by the repository 200g), power 
user 112d may add her own restrictions to such usage 
permissions (e.g., restricting certain members of power user 
112d's household using the settop appliance to certain times of 
day, amounts of usage, etc. based on their user identification 
information). Power user 112d may then transmit such VDE 
protected content and usage permissions to the laptop computer 
3506 and the settop appliance 3508 using VDE secure 



communications techniques. In this case, power user 112d has 
redistributed permissions from the desktop computer 3504 to the 
settop appliance 3508 and the laptop computer 3506, and 
periodically the settop appliance and the laptop computer may be 
required to report content usage information to the desktop 
computer, which in turn may aggregate, and/or otherwise 
process, and report user usage information to the repository 
200g. 

User 112e and/or user 112f may receive usage permissions 
and VDE protected content from commercial content repository 
200g. These users may be able to use such content in ways 
authorized by such usage information. In contrast to power user 
112d, these users may not have requested and/or received 
redistribution permissions from the repository 200g. In this case, 
these users may still be able to transfer some or all usage rights 
to another electronic appliance 600, and/or they may be 
permitted to move some of their rights to another electronic 
appliance, if such transferring and/or moving is permitted by the 
usage permissions received from the repository 200g. In this 
case, such other appliances may be able to report usage 
information directly to the repository 200g. 

In this example, corporate content repository 702 within 
corporation 700 may receive VDE protected content and 



distribution permissions from creator 102* The distribution 
permissions received by corporate repository 702 may, for 
example, include restrictions that limit repository 702 to 
distribution activities within corporation 700. 

The repository 702 may, for example, employ an automated 
system operating in conjunction with a VDE secure subsystem to 
receive and/or transmit VDE protected content, and/or 
redistribution and/or usage permissions. In this case, an 
automated system may, for example, rely on criteria defined by 
corporate policies, departmental policies, and/or user preferences 
to determine the character of permissions and/or content 
delivered to various parties (corporation groups and/or 
individuals) within corporation 700. Such a system may, for 
example, automatically produce redistribution permissions for a 
departmental content repository 704 in response to corporation 
700 receiving distribution permissions from creator 102, and/or 
produce usage permissions for user 112j and/or user 112k. 

The departmental repository 704 may automatically 
produce usage permissions for user 112g, user 112h, and/or user 
112i. Such users may access content from the corporate content 
repository 702, yet receive usage permissions from departmental 
repository 704. In this case, user 112g, user 112h, and/or user 
112i may receive usage permissions from departmental 



repository 704 that incorporate departmental restrictions in 
addition to restrictions imposed by senior control information (in 
this example, from creator 102, as may be modified by corporate 
repository 702, as may be further modified by departmental 
repository 704, that reflect a VDE extended agreement 
incorporating commercial requirements of creator 102 and 
corporation 700 in addition to corporate and/or departmental 
policies and agreements with corporate personnel of corporation 
700). 

Example — "Virtual Silicon Container" 

As discussed above, VDE in one example provides a 
• virtual silicon container" ("virtual black box") in that several 
different instances of SPU 500 may securely communicate 
together to provide an overall secure hardware environment that 
"virtually" exists at multiple locations and multiple electronic 
appliances 600. Figure 87 shows one model 3600 of a virtual 
silicon container. This virtual container model 3600 includes a 
content creator 102, a content distributor 106, one or more 
content redistributors 106a, one or more client administrators 
700, one or more client users 3602, and one or more 
clearinghouses 116. Each of these various VDE participants has 
an electronic appliance 600 including a protected processing 
environment 655 that may comprise, at least in part, a silicon- 
based semiconductor hardware element secure processing unit 



500. The various SPUs 500 each encapsulate a part of the virtual 
distribution environment, and thus, together form the virtual 
silicon container 3600. 

Example - Testing/Examinations 

A scheduled SAT examination for high school seniors is 
prepared by the Educational Testing Service. The examination is 
placed in a VDE container for scheduled release on November 15, 
1994 at 1:00 PM Eastern Standard time. The SAT prepares one 
copy of the container for each school or other location which will 
conduct the examination. The school or other location ("test site") 
will be provided with a distributed examination container 
securely containing the VDE identification for the 
"administration" electronic appliance and/or test administrator at 
the test site (such as, a testing organization) and a budget 
enabling, for example, the creation of 200 test VDE content 
containers. Each container created at the test site may have a 
permissions record containing secure identification information 
for each electronic appliance 600, on the test site's network, that 
will be used by a test taker, as well as, for example, an 
identification for the student who will take the test. The student 
identification could, for example, be in the form of a secure PIN 
password which is entered by the student prior to taking the test 
fa test monitor or administrator might verify the student 



identification by entering in a PIN password). Of course, 
identification might take the firm of automated voice recognition, 
handwriting recognition (signature recognition), fingerprint 
information, eye recognition, or similar one or more recognition 
forms which may be used either to confirm the identity of the test 
taker (and/or test monitor/administrator) and/or may be stored 
with the test results in a VDE container or the like or in a 
location pointed to by certain container information. This 
identification may be stored in encrypted or unencrypted form. If 
stored in encrypted or otherwise protected form, certain 
summary information, such as error correction information, may 
be stored with the identification information to authenticate the 
associated test as corresponding to the identification. 

As the student takes the test using the computer terminal, 
the answers selected may be immediately securely stored (but 
may be changed by the student during the test session). Upon 
the completion of the test, the student's answers, along with a 
reference to the test, are securely stored in a VDE reporting 
object which is passed along to the network to the test 
aojninistrator and the adrninistration electronic appliance 600. 
All test objects for all students could then be placed in a VDE 
object 300 for communication to the Educational Testing Service, 
along with whatever other relevant information (which may also 
be secured by VDE 100), including summary information giving 



average and mean scores, and other information that might be 
desirable to summarize and/or act as an authentication of the 
test objects sent. For example, certain information might be sent 
separately from each student summary object containing 
information which helps validate the object as an "authentic" test 
object. 

Applying VDE to testing scenarios would largely eliminate 
cheating resulting from access to tests prior to testing (normally 
the tests are stolen from a teacher or test administrator). At 
ETS, individuals who have access to tests could be limited to only 
a portion of the test to eliminate the risk of the theft of a "whole" 
test. Employing VDE would also ensure against processing 
errors or other manipulation of test answers, since absolutely 
authentic test results can be archived for a reasonable period of 
time. 

Overall, employing VDE 100 for electronic testing will 
enable the benefits of electronic testing to be provided without 
the substantial risks associated with electronic storing, 
communicating, and processing of test materials and testing 
results. Electronic testing will provide enormous efficiency 
improvements, significantly lowering the cost of conducting and 
processing tests by eliminating printing, shipping, handling, and 
human processing of tests. At the same time, electronic testing 



will allow users to receive a copy (encrypted or unencrypted) of 
their test results when they leave the test sessions. This will 
help protect the tested individual against lost of, or improperly 
processed, test results. Electronic testing employing VDE 100 
may also ensure that timing related variables of testing (for 
example precise starting, duration, and stopping times) can be 
reliably managed. And, of course, proper use of VDE 100 for the 
testing process can prevent improper access to test contents prior 
to testing and ensure that test taking is properly audited and 
authenticated, that is which person took which test, at which 
time, on which electronic appliance, at which location. Retesting 
due to lost, stolen, improperly timed, or other variables can be 
avoided or eliminated. 

VDE assisted testing may, of course, be employed for many 
different applications including secure identification of 
individuals for security/authentication purposes, for employment 
(e.g. applying for jobs) applications, and for a full range of 
evaluation testing. For example, an airline pilot, or a truck, 
train, or bus driver might take a test immediately prior to 
departure or during travel, with the test evaluating alertness to 
test for fatigue, drug use, etc. A certain test may have a different 
order and/or combination of test activities each time, or each 
group of times, the test is taken. The test or a master test might 
be stored in a VDE container (the order of, and which, test 



questions might be determined by a process executed securely 
within an PPE 650). The test responses may be encrypted as 
they occur and either locally stored for aggregated (or other test 
result) transmission or dynamically transmitted (for example, to 
a central test administration computer). If the test taker "flunks" 
the test, perhaps he or she is then prevented from operating the 
vehicle, either by a local PPE 650 issuing control instructions to 
that effect on some portion of the vehicle's electronic control 
system or a local PPE failing to decrypt or otherwise provide 
certain key information required for vehicle operation. 

Example — Appliance Rental 

Through use of the present invention, electronic appliances 
can be "leased" or otherwise provided to customers who, rather 
than purchasing a given appliance for unlimited usage, may 
acquire the appliance (such as a VCR, television, microwave 
oven, etc.) and be charged according to one or more aspects of 
use. For example, the charge for a microwave might be for each 
time it is used to prepare an item and/or for the duration of time 
used. A telephone jack could be attached, either consistently or 
periodically, to an inexpensive modem operatively attached or 
within the microwave (the modem might alternatively be located 
at a location which services a plurality of items and/or functions 
- such as burglar alarm, light and/or heat control). Alternatively, 



such appliances may make use of a network formed by the power 
cables in a building to transmit and receive signals. 

At a periodic interval, usage information (in summary form 
and/or detailed) could be automatically sent to a remote 
information utility that collects information on appliance usage 
(the utility might service a certain brand, a certain type of 
appliance, and/or a collection of brands and/or types). The usage 
information would be sent in VDE form (e.g. as a VDE object 
300). The information utility might then distribute information 
to financial clearinghouse(s) if it did not itself perform the billing 
function, or the information "belonging" to each appliance 
manufacturer and/or lessor (retailer) might be sent to them or to 
their agents. In this way a new industry would be enabled of 
leased usage of appliances where the leases might be analogous 
to car leasing. 

With VDE installed, appliances could also be managed by 
secure identification (PIN, voice or signature recognition, etc.). 
This might be required each time a unit is used, or on some 
periodic basis. Failure to use the secure identification or use it on 
a timely basis could disable an appliance if a PPE 650 issued one 
or more instructions (or failed to decrypt or otherwise provide 
certain information critical to appliance operation) that 
prevented use of a portion or all of the appliance's functions. 



This feature would greatly reduce the desirability of stealing an 
electronic appliance. A further, allied use of VDE is the 
"registration" of a VDE secure subsystem in a given appliance 
with a VDE secure subsystem at some control location in a home 
or business. This control location might also be responsible for 
VDE remote communications and/or centralized administration 
(including, for example, restricting your children from viewing R 
rated movies either on television or videocassettes through the 
recognition of data indicating that a given movie, song, channel, 
game, etc. was R rated and allowing a parent to restrict viewing 
or listening). Such a control location may, for example, also 
gather information on consumption of water, gas, electricity, 
telephone usage, etc. (either through use of PPEs 650 integrated 
in control means for measuring and/or controlling such 
consumption, or through one or more signals generated by 
non-VDE systems and delivered to a VDE secure subsystem, for 
example, for processing, usage control (e.g. usage limiting), 
and/or billing), transmit such information to one or more utilities, 
pay for such consumption using VDE secured electronic currency 
and/or credit, etc. 

In addition, one or more budgets for usage could be 
managed by VDE which would prevent improper, excessive use of 
. a certain, leased appliance, that might, for example lead to 
failure of the appliance, such as making far more copies using a 



photocopier than specified by the duty cycle. Such improper use 
could result in a message, for example on a display panel or 
television screen, or in the form of a communication from a 
central dearinghouse, that the user should upgrade to a more 
robust model. 

While the invention has been described in connection with 
what is presently considered to be the most practical and 
preferred embodiment, it is to be understood that the invention is 
not to be limited to the disclosed embodiment, but on the 
contrary, is intended to cover various modifications and 
equivalent arrangements included within the spirit and scope of 
the appended claims. 



WE CLAIM: 

1. A method for secure content delivery including: 

a) encapsulating digital information within one or more 
digital containers; 

b) encrypting at least one portion of said digital 
information; 

c) associating at least partially secure control 
information for managing interaction with said 
encrypted digital information and/or the digital 
container; 

d) delivering one or more of said one or more digital 
containers to a digital information user; 

e) employing a protected processing environment for 
securely controlling decryption of at least a portion of 
said digital information. 

2. A system for secure content delivery including: 
encrypting means for encrypting at least one portion of 

digital information; 

container processing means for encapsulating digital 
information within one or more digital containers and for 
associating at least partially secure control information for 
managing interaction with said encrypted digital information; 



delivery means for delivering one or more of said one or 
more digital containers to a digital information user, and 

at least one protected processing environment for securely 
controlling decryption of at least a portion of said digital 
information. 

3. A method for secure digital information delivery 
characterized by the steps of: (a) encrypting at least a portion of 
said digital information through the use of a first at least one 
VDE node, (b) creating and encrypting, through the use of said 
first at least one VDE node, control information to control use of 
at least a portion of said digital information by plural, users, (c) 
securely providing said control information to said plural users, 
and (d) employing at least one VDE node different from said first 
at least one VDE node to process at least portions of said control 
information and to control use of said encrypted digital 
information by said users. 

4. A system for secure digital information delivery 

characterized by: 

a first at least one VDE node for encrypting at least a 
portion of said digital information, 

means for creating and encrypting, through the use of said 
first at least one VDE node, control information to control use of 
at least a portion of said digital information by plural, users, 



means for securely providing said control information to 
said plural users, and 

at least one VDE node different from said first at least one 
VDE node for processing at least portions of said control 
information and to control use of said encrypted digital 
information by said users. 

5. A method for secure content delivery wherein at least 
partially encrypted content is encapsulated within at least one 
digital container and the digital container is delivered to a digital 
information user, the method characterized by the steps of: 

associating, with the encapsulated content and/or the 
digital container, at least partially secure control information for 
managing interaction with the container and/or the content; and 

employing a protected processing environment for 
securely controlling decryption of at least a portion of the 
encrypted content based at least in part on the control 
information. 

6. A system for secure content delivery wherein at least 
partially encrypted content is encapsulated within at least one 
digital container and the digital container is delivered to a digital 
information user, the system characterized by: 

a data structure that associates, with the encapsulated 
content and/or the digital container, at least partially secure 
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control information for managing interaction with the 
information; and 

a protected processing environment for securely 
controlling decryption of at least a portion of the encrypted 
content based at least in part on the control information. 

7. A method for secure digital information delivery 
characterized by the steps of: (a) encrypting at least a portion of 
said digital information, (b) associating protected control 
information to at least a portion of said digital information, and c) 
providing at least a portion of said encrypted digital information 
to a first user and at least in part controlling use of at least a 
portion of said encrypted digital information through the use of 
at least a portion of said protected control information, wherein 
said first user further provides at least one of (a) a copy of said at 
least a portion of said encrypted digital information , or (b) said 
encrypted digital information, to a second user, and wherein said 
second user associates further control information with said 
encrypted digital information for use in controlling use of said 
encrypted digital information by a third user. 

8. A system for secure digital information delivery 
characterized by: 

means for encrypting at least a portion of said digital 
information, 



means for associating protected control information to at 
least a portion of said digital information, 

means for providing at least a portion of said encrypted 
digital information to a first user 

means for at least in part controlling use of at least a 
portion of said encrypted digital information through the use of 
at least a portion of said protected control information, 

means for allowing the first user to provide at least one of 
(a) a copy of said at least a portion of said encrypted digital 
information, or (b) said encrypted digital information, to a second 
user, and 

means for allowing said second user to associate further 
control information with said encrypted digital information for 
use in controlling use of said encrypted digital information by a 
third user. 

9. A method for secure digital transaction management 
including: 

a) encrypting digital information at a first location; 

b) enabling a first party to securely associate at least 
one control with said information for use in ensuring 
at least one consequence of use of said information; 

c) enabling one or more additional parties to securely 
associate at least one further control with said 



information for use in ensuring at least one 

consequence of use of said information; 
d) distributing at least a portion of said information to 

a party other than the first and additional parties at 

a location different from the locations of the first and 

additional locations; and 
f) decrypting at least a portion of said information at 

said third location, and ensuring said consequences 

of use of said information. 

10. A system for secure digital transaction management 
including interconnected structures for performing the following 
functions: 

a) encrypting digital information; 

b) enabling a first party to securely associate at least 
one control with said information for use in ensuring 
at least one consequence of use of said information; 

c) enabling one or more additional parties to securely 
associate at least one further control with said 
information for use in ensuring at least one 
additional consequence of use of said information; 

d) distributing at least a portion of said information to 
a further party; and 

e) decrypting at least a portion of said information; and 

f) securely ensuring said consequences. 
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11. A system for secure digital transaction management 
wherein digital information is encrypted by a first party at a first 
location and distributed', characterized by: 

a first protected processing environment for enabling the 
first party to securely associate at least a first control with said 
information, 

a further protected processing environment for enabling 
the further party to securely associate at least a further control 
with said information, and 

a still further protected processing environment for 
decrypting at least a portion of said information while controlling 
at least one consequence of use of the information based at least 
in part on the first and further controls. 

12. A method for secure digital transaction management 
wherein digital information is encrypted by a first party at a first 
location and distributed, characterized by the following steps: 

enabling the first party to securely associate at least a 
first control with said information, 

enabling a further party to securely associate at least a 
further control with said information, and 

transmitting the first and further controls; and 

decrypting at least a portion of said information while 
controlling at least one consequence at least in part on the 
transmitted controls. 



13. A method for securely automating distributed 
electronic processes including: 

a) providing secure, interoperable, general purpose 
rights management processing means to multiple, 
parties; 

b) establishing secure process management controls for 
automatically, at least partially remotely, and 
securely supporting requirements related to 
electronic events; 

c) securely distributing process management controls 
to party sites; 

d) securely maintaining at least a portion of said 
process management controls under the control of 
party processing means at said party sites; 

e) automatically managing electronic processes at said 
party sites to enforce interests related to said 
electronic content. 

14. A system for securely automating distributed 
electronic processes including: 

interoperable rights management processing means 
disposed at multiple parties' sites; 

control establishing means for establishing secure process 
management controls; for remotely, automatically, and securely 
supporting requirements related to electronic events; and for 



securely distributing process management controls to party 
sites; 

security means for securely maintaining at least a portion 
of said process management controls under the control of 
processing means at said party sites; and 

managing means for automatically managing electronic 
processes at plural party sites to enforce interests related to said 
electronic events. 

15. A method for automating distributed electronic 
processes using interoperable processors at multiple sites, 
characterized by the following steps: 

securely distributing, to the processors, process 
management controls for automatically, and securely supporting 
requirements related to electronic events; 

securely maintaining at least a portion of said process 
management controls under the control of the processors; and 

automatically managing, in a distributed manner with 
the processors, electronic processes at the multiple sites to 
enforce interests related to electronic events. 

16. A system for automating distributed electronic 
processes using interoperable processors at multiple sites, 
characterized by the following: 



distributing means connected to the processors for 
securely distributing, to the processors, process management 
controls for remotely, automatically, and securely supporting 
requirements related to electronic events; 

process control means for securely maintaining at least a 
portion of said process management controls under the control of 
the processors; and 

management means for automatically managing, in a 
distributed manner with the processors, electronic processes at 
the multiple sites to enforce the interests related to the electronic 
events. 

17. A method of securely enforcing a rights seniority 
system characterized by the steps of: 

allowing a first user to create at least one control over 
electronic content; and 

allowing a second user to contribute at least one further 
control over electronic content and/or alter the control in place, 
the second control being subject to the first control. 

18. A system for securely enforcing a rights seniority 
system characterized by: 

a first secure environment for allowing a first user to 
contribute at least one control over electronic content; and 



a second secure environment for allowing a second user to 
contribute at least one further control over electronic content 
and/or alter the control in place, the second control being subject 
to the first control. 

19. A method of securely enforcing a rights seniority 
system characterized by the step of allowing a first user to create 
at least one electronic control that at least in part dictates the 
rights a second user has to create further electronic controls over 
the use of and/or access to electronic content. 

20. A system for securely enforcing a rights seniority 
system characterized by at least one means for allowing a first 
user to create at least one electronic control that at least in part 
dictates the rights a second user has to create further electronic 
controls over the use of and/or access to electronic content. 

21. A method for employing protected processing 
environments including: 

a) distributing interoperable protected processing 
environments to plural parties; 

b) providing a first interoperable protected processing 
environment for use by a first party to enable said 
party to (a) encrypt digital information, and (b) 
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create control information for managing at least one 
aspect of use of said digital information; 

c) encrypting said digital information in response to 
one or more instructions from said first party; 

d) making said digital information available to a second 
party; 

e) through the use of a second interoperable protected 
processing environment, satisfying requirements 
enforced by said control information and allowing 
said second party to use at least a portion of said 
digital information; 

f) through the use of said second interoperable 
protected processing environment securely reporting 
information reflecting at least one aspect of said 
second party use of said digital information. 

22. A system for employing protected processing 
environments including: 

interoperable protected processing environments 
distributed to plural parties, including a first interoperable 
protected processing environment for use by a first party to 
enable said party to (a) encrypt digital information, and (b) create 
control information for managing at least one aspect of use of 
said digital information, and further including a second 
interoperable protected processing environment; 



means for encrypting said digital information in response 
to one or more instructions from said first party, and for making 
said digital information available to a second party; 

means for a second interoperable protected processing 
environment to satisfy requirements enforced by said control 
information and to allow said second party to use at least a 
portion of said digital information; and to securely report 
information reflecting at least one aspect of said second party's 
use of said digital information. 

23. A method for employing protected processing 
environments distributed to plural parties characterized by the 
following steps: 

using a first protected processing environment to encrypt 
digital information, and control information specifying 
requirements for managing at least one aspect of use of said 
digital information; 

using a second protected processing environment 
interoperable with the first protected processing environment to 
enforce the requirement specified by said control information and 
conditionally allowing use of at least a portion of said digital 
information; and 

using the second protected processing environment to 
report information reflecting at least one aspect of use of said 
digital information. 



24. A system for employing protected processing 
environments distributed to plural parties characterized by: 

a first protected processing environment to encrypt digital 
information, and for handling control information specifying 
requirements for managing at least one aspect of use of said 
digital information; 

a second protected processing environment interoperable 
with the first protected processing environment for enforcing at 
least one requirement specified by said control information and 
conditionally allowing use of at least a portion of said digital 
information; and for reporting information reflecting at least one 
aspect of use of said digital information. 

25. A secure network architecture comprising multiple 

cooperating interconnected nodes having protected processing 

environments, at least a portion of said nodes being able to 

* 

intercommunicate, characterized in that VDE-protected 
information can be moved from a source node to a destination 
node and processed at least in part by the destination node. 

26. In a secure network architecture comprising multiple 
cooperating interconnected nodes having protected processing 
environments, the nodes being able to intercommunicate, a 
method comprising the step of moving VDE-protected 



information from a source node to a destination node and 
processed at least in part by the destination node. 

27. A secure local area network topology comprising 
multiple cooperating interconnected nodes, characterized in that 
at least some of the nodes comprise network workstations with 
software defining protected processing environments, and at 
least one of the nodes comprises a secure database server that 
provides information in protected form for processing by the 
network workstation protected processing environments. 

28. In a secure local area network topology comprising 
multiple cooperating interconnected nodes, a method 
characterized by the steps of: 

executing, at least in part with network workstations, 
software defining protected processing environments, and 

providing, with a secure database server, information for 
processing by the network workstation protected processing 
environments. 

29. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that at least one of the plural 
nodes provides a protected processing environment that performs 
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a server function for a client comprising at least a portion of the 
protected processing environment of at least one other node. 

30. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by providing, with at least 
one of the plural nodes, a protected processing environment; and 
performing, with the protected processing environment, a server 
function for a client comprising at least a portion of the protected 
processing environment of at least one other node. 

31. A method for securely managing electronic 
negotiations related to electronic commerce value chain activities 
including: 

a) employing a protected processing environment by a 
first party to securely specify rules and/or controls 
for managing an electronic commerce process; 

b) securely making said specified rules and/or controls 
available to a second party; 

c) employing a protected processing environment 
different from said first protected processing 
environment to further securely specify rules and/or 
controls for managing at least one commerce process 
related to the common commercial interests of said 
first party and said second party; 
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d) employing said protected processing environment to 
securely electronically negotiate at least one 
aggregate rules and/or controls set representing the 
electronic interests of both said first party and said 
second party; 

e) employing a protected processing environment to 
manage said electronic commerce process consistent 
with at least a portion of said aggregate rules and/or 
controls set. 

32. A system for securely managing electronic negotiations 
related to electronic commerce value chain activities including: 

a first party's protected processing environment for 
securely specifying rules and/or controls for managing an 
electronic commerce process, and for securely making said 
specified rules and/or controls available to a second party; 

a second party's protected processing environment 
different from said first party's protected processing environment 
to further securely specify rules and/or controls including means 
for managing at least one commerce process related to the 
common commercial interests of said first party and said second 
party; 

at least one of the first party's and the second party's 
protected processing environment for securely electronically 
negotiating at least one aggregate rules and/or controls set 
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representing the electronic interests of both said first party and 

said second party; and 

at least one of the first party's and the second party's 
protected processing environment including means for managing 
said electronic commerce process consistent with said at least a 
portion of said aggregate rules and/or controls set. 

33. A method for securely managing electronic 
negotiations related to electronic commerce value chain activities 
through use of first and second protected processing environment 

characterized by: 

using the first environment, securely specifying rules 
and/or controls for managing an electronic commerce process; 

using the second environment, further securely specifying 
rules and/or controls for managing at least one commerce process 
related to the commercial interests of a first and a second party; 

employing at least one of the first and second protected 
processing environments to securely electronically negotiate at 
least one aggregate rules and/or controls set representing the 
electronic interests of the first party and said second party; and 

employing at least one of the first and second protected 
processing environment to manage said electronic commerce 
process consistent with at least a portion of said aggregate rules 
and controls set. 



34. A system for securely managing electronic negotiations 
related to electronic commerce value chain activities through use 
of first and second protected processing environment 
characterized by: 

the first environment including means for securely 
specifying rules for managing an electronic commerce process; 

the second environment including means for further 
securely specify rules for managing at least one commerce 
process related to the commercial interests of first and second 
parties; 

at least one of the first and second protected processing 
environments including means for securely electronically 
negotiating at least one aggregate rules set at least partially 
representing the electronic interests of said first party and said 
second party; and 

at least one of the first and second protected processing 
environment including means for managing said electronic 
commerce process consistent with said at least a portion of said 
aggregate rules set. 

35. A method for managing a distributed electronic 
commerce environment including: 

a) establishing a secure, certificate authority for 
authenticating a user identity for an electronic 
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commerce participant wherein said identity includes 
one or more user class parameters; • 

b) certifying said user identity through the use of one 
or more certificates enabled by said certificate 
authority, 

c) controlling the use of distributed electronic 
information based at least in part on class parameter 
information included in such certified identity. 

36. A system for securely managing a distributed 
electronic commerce environment including: 

means for establishing a user identify for an electronic 
commerce participant wherein said identity includes one or more 
user class parameters; 

a certificate authority for authenticating such user 
identity by certifying said user identity through the use of one or 
more certificates enabled by said certificate authority; and 

means for controlling the use of distributed electronic 
information based at least in part on class parameter information 
included in such certified identity. 

37. A method for securely managing a distributed 
electronic commerce environment to allow interaction with an 
electronic commerce participant having a user identity that is 
certified by a certificate authority, characterized by: 



establishing a user identity; 

certifying the user identity and the user class parameter; 

and 

associating, with the user identity, at least one user class 
parameter, wherein said certified class parameter, at least in 
part, is used to control use of distributed electronic information. 

38. A system for managing a distributed electronic 
commerce environment to allow interaction with an electronic 
commerce participant having a certified user identity, 
characterized by: 

means for associating at least one user class parameter 
with an established user identity; 

means for ascertaining the authenticity of the user identity 
and/or the user class parameter; and 

means for controlling use of distributed electronic 
information based at least in part on said status. 

39. A system as in claim 38 wherein the class parameter 
represents the user's age, and the controlling means includes 
means for controlling the use of distributed electronic 
information based on the user's age. 

40. A method of securely establishing user identity 
through use of certificates, the method characterized by: 



presenting an electronic token reflecting at least one user 

class characteristic; 

determining whether an electronic certificate authenticates 
the user class characteristic reflected by the token; and 

using the token as a basis for granting rights. 

41. A system for identifying a user through use of 
certificates, the system characterized by: 

means presenting an electronic token reflecting at least 
one user class characteristic; 

means for obtaining an electronic certificate; 

means for determining whether the electronic certificate 
authenticates the user class characteristic reflected by the token; 
and 

means for using the certified, authenticated token as a 
basis for granting rights. 

42. A system for securely managing a distributed 
electronic commerce environment including: 

means for identifying an electronic commerce participant 

by specifying at least one user category; 

means for authenticating such user identity; and 
means for controlling the use of distributed electronic 

information based at least in part on the user category. 



43. A method for securely managing a distributed 
electronic commerce environment to allow interaction with an 
electronic commerce participant, characterized by: 

establishing a user identity and an associated user class 
parameter; and 

using the class parameter to, at least in part, control use of 
distributed electronic information. 

44. A system for managing a distributed electronic 
commerce environment to allow interaction with an electronic 
commerce participant, characterized by: 

means for associating at least one user class parameter 
with a user identity; 

means for authenticating the user identity and/or the user 
class parameter; and 

means for controlling use of distributed electronic 
information based at least in part on said status. 

45. A system as in claim 44 wherein the class parameter 
represents the user's age, and the controlling means includes 
means for controlling the use of distributed electronic 
information based on the user's age. 

46. A method of securely establishing user identity, the 
method characterized by: 
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presenting an electronic token reflecting at least one user 

class characteristic; 

determining the user class characteristic reflected by the 

token is authentic; and 

using the token as at least a partial basis for granting 

rights. 

47. A system for securely establishing user identity 

characterized by: 

means presenting an electronic token reflecting at least 

one user class characteristic; 

authenticating the user class characteristic reflected by the 

token; and 

means for using the authenticated token as a basis for 
granting rights. 

48. A method of authenticating a user identity, the method 

characterized by: 

receiving a certificate request and associated user identity; 

and 

issuing an electronic certificate for use in authenticating at 
least one user class characteristic associated with the user 
identity for granting rights based on the user class characteristic. 



49. A system for authenticating user identity, 
characterized by: 

means for receiving a certificate request and associated 
user identity; and 

means for issuing an electronic certificate for use in 
authenticating at least one user class characteristic associated 
with the user identity for granting rights based on the user class 
characteristic. 



50. A method of securely establishing user identity, the 
method characterized by: 

receiving a certificate request; and 

issuing an electronic certificate specifying at least one user 
class characteristic. 

51. A system for securely establishing user identity 
through use of certificates, characterized by: 

means for receiving a certificate request and associated 
user identity; and 

means for issuing an electronic certificate specifying at 
least one user class characteristic. 
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52. A method or system of managing rights characterized 
in that a cryptographicaUy signed token is used to certify 
membership in a class, the token is authenticated, and the class 
membership represented by the token is used as a basis for 
granting and/or withholding rights and/or permissions. 

53. A method or system of managing rights characterized 
that a cryptographicaUy signed token is used to certify 
mbership in a class, the status of such token is ascertained, 

and the class membership represented by the token is used as a 
basis for allowing a user presenting the token to create electronic 
rules. 

54. A method or system of managing rights characterized 
in that a cryptographicaUy signed token is used to certify 
membership in a class, the token is validated, and the class 
membership represented by the token is used as a basis for 
aUowing a user presenting the token to exercise rights under 
electronic rules. 

55. A method for enabling a distributed electronic 
commerce electronic agreement system including: 

a) enabling distributed, interoperable secure client 
protected processing environment nodes; 



b) establishing at least one system wide secure 
communications key; 

c) employing public key encryption for communications 
between plural client nodes; 

d) supporting the delivery of electronic control 
information by individual clients wherein said 
control information at least in part specifies their 
respective electronic commerce agreement rights; 

e) supporting at least one protected processing 
environment for determining the respective and/or 
collective rights of said clients by establishing one or 
more electronic agreements based at least in part on 
said secure delivery of electronic control information; 

f) employing a secure software container data control 
structure for ensuring persistent maintenance of the 
electronic rights of the clients; 

g) using secure software containers which provide for 
data structures that support rules and/or controls 
corresponding to electronic commerce model 
agreement enforcement. 

56. A distributed electronic agreement system including: 
plural distributed, interoperable secure client protected 
processing environment nodes for supporting delivery of 
electronic control information by individual clients wherein said 
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control information at least in part specifies said client's 
respective electronic commerce model agreement rights, and for 
employing public key encryption and authentication for 
communications between said plural client nodes; 

means coupled to said nodes for establishing at least one 
system wide secure communications key; and 

at least one protected processing environment for: 
(a) determining the respective and/or collective rights of 
electronic commerce model clients by establishing 
one or more electronic agreements based at least in 
part on said secure delivery of electronic control 
information; 

(b) employing a secure software container data control 
structure for ensuring persistent maintenance of the 
electronic rights of commerce model clients; and 

(c) using secure software containers which provide for 
data structures that support controls corresponding 
to electronic commerce model agreement 
enforcement. 

57. A method for enabling a distributed electronic 
commerce electronic agreement system including distributed, 
interoperable secure client protected processing environment 
nodes employing at least one system wide secure communications 
key, employing public key encryption and authentication for 



communications between plural client nodes, and employing an 
certification authority for establishing client identity, the method 
characterized by: 

supporting the , secure delivery of electronic commerce 
model agreement rights control information; 

determining the respective and/or collective rights of 
electronic commerce model clients by establishing one or more 
electronic agreements based at least in part on said secure 
delivery of the electronic control information; 

employing a secure software container data control 
structure for ensuring remote, persistent maintenance of the 
electronic rights of commerce model clients; and 

using secure software containers which provide for data 
structures supporting rules and controls corresponding to 
electronic commerce model agreement enforcement. 

58. A distributed electronic commerce electronic 
agreement system including: 

distributed, interoperable secure client protected 
processing environment nodes employing at least one system 
wide secure communications key, employing public key 
encryption and authentication for communications between 
plural client nodes, employing an certification authority for 
establishing client identity, and supporting the, secure delivery of 
electronic commerce model agreement rights control information; 
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means disposed in at least one node for determining the 
respective and/or collective rights of electronic commerce model 
clients by establishing one or more electronic agreements based 
at least in part on said secure delivery of the electronic control 
information; and 

means disposed in at least one node for employing a secure 
software container data control structure for ensuring remote, 
persistent maintenance of the electronic rights of commerce 
model clients, and for using secure software containers which 
provide for data structures supporting rules and controls 
corresponding to electronic commerce model agreement 
enforcement. 

59. A method of securely handling electronic currency 
characterized by the following steps: 

packaging electronic currency within a software container, 

and 

delivering the software container as payment for goods or 
services. 

60. A system for securely handling electronic currency 

characterized by: 

means for packaging electronic currency within a software 

container, and 



means for delivering the software container as payment for 
goods or services. 

61. A method or system for managing rights within an 
organization characterized in that electronic containers are 
distributed within the organization, the electronic containers 
having controls associated therewith, the controls enforcing, at 
least in part, an organizational hierarchy relating to the use of 
the containers and/or the contents thereof. 

62. A method of organizational rights management 
characterized by the steps of: 

distributing an electronic container within an organization 

and 

restricting usage, access and/or further distribution of the 
electronic container or the contents thereof within or outside of 
the organization based on electronic controls associated with the 
electronic container. 

63. A system for organizational rights management 
characterized by: 

means for distributing an electronic container and 
means for restricting usage, access and/or further 
distribution of the electronic container or the contents thereof 



within or outside of the organization based on electronic controls 
associated with the electronic container. 

64. A method of organizational rights management 
characterized by the steps of: 

distributing electronic containers within an organization, 

and 

using the electronic containers, at least in part, to 
administer content usage by persons within the organization. 

65. A system for organizational rights management 

characterized by: 

means for distributing electronic containers within an 

organization, and 

means for using the electronic containers, at least in part, 
to administer content usage by persons within the organization. 

66. A method of organizational rights management 
characterized by the steps of: 

distributing electronic containers within an organization, 

and 

using the electronic containers, at least in part, to 
administer use of money within the organization. 

67. A system for organizational rights management 
characterized by electronic containers distributed within an 



organization for, at least in part, administering use of money 
within the organization. 

68. A method of organizational rights management 
characterized by the steps of: 

distributing protected processing environments within an 
organization, and 

using the environments to, at least in part, to administer 
content usage by persons within the organization. 

69. A system for organizational rights management 
characterized by protected processing environments distributed 
within an organization, for, at least in part, administering 
content usage within the organization. 

70. A method of organizational rights management 
characterized by the steps of: 

distributing protected processing environments within an 
organization, and 

using the processing environments to, at least in part, to 
administer use of money by persons within the organization. 

71. A system for organizational rights management 
characterized by plural protected processing environments 



distributed within an organization for, at least in part, 
administering use of money within the organization. 

72. A rights management appliance including: 
a user input device, 

a user display device, 

at least one processor, and 

at least one element defining a protected processing 
environment, 

characterized in that the protected processing environment 
stores and uses permissions, methods, keys, programs and/or 
other information to electronically manage rights. 

73. In a rights management appliance including: 
a user input device, 

a user display device, 

at least one processor, and 

at least one element defining a protected processing 
environment, 

a method of operating the appliance characterized by the 
step of storing and using permissions, methods, keys, programs 
and/or other information to electronically manage rights. 

74. A rights management appliance including at least one 
processor element at least in part defining a protected processing 



environment, characterized in that the protected processing 
environment stores and uses permissions, methods, keys, 
programs and/or other information to electronically manage 
rights. 

75. In a rights management appliance including at least 
one processor element at least in part defining a protected 
processing environment, a method comprising storing and using 
permissions, methods, keys, programs and/or other information 
to electronically manage rights. 

76. A method of electronically storing information in a 
repository and distributing it on request, characterized in that 
the information is protected by associating electronic controls 
with the information, the electronic controls serving to enforce 
rights in the information. 

77. A system for electronically storing information in a 
repository and distributing it on request, characterized by means 
for protecting information by associating electronic controls with 
the information, and further including means for using the 
electronic controls to enforce rights in the information. 
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78. A self-protecting electronic container comprising: 
an electronic container structure for containing digital 

information, and 

an electronic protection mechanism that protects or 
destroys the digital information in the event of tampering. 

79. A method for a self-protecting electronic container 
comprising an electronic container structure for containing 
digital information, the method characterized by detecting an 
attempt at tampering and protecting or destroying the digital 
information in the said attempt. 

80. A method of creating a self-protecting container system 

comprising: 

providing at least one property, 

providing at least one attribute, 

providing at least one cryptographic key, 

providing at least one organizational structure relating the 
key to the property and/or attribute, and 

encapsulating the property, the attribute, the 
cryptographic key and the organizational structure, either 
explicitly or by reference, into an electronic container structure. 

81. A self-protecting container system comprising: 
at least one property, 



at least one attribute, 

at least one cryptographic key, and 

at least one organizational structure relating the key to the 
property and/or attribute. 

82. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that each node can perform self- 
administering processes in response to electronic components. 

83. A self-administering electronic component comprising: 
at least one method for performing at least a portion of a 

transaction, 

at least one method for generating audit information, and 
at least one method for securely receiving and interpreting 
administrative information. 

84. A self-administering electronic component performing 
the following methods: 

at least one method for performing at least a portion of a 
transaction, 

at least one method for generating audit information, and 
at least one method for securely receiving and interpreting 
administrative information. 



WO 96/27155 



85. A self-describing electronic component defining at least 
one parameter and/or function, characterized in that the 
component includes at least one secure, descriptive portion used 
to create a human readable interface describing the parameter 
and/or function. 

86. A method for processing a self-describing electronic 
component defining at least one parameter and/or function, 
characterized by the step of creating, at least in part with the 
component, a human readable interface describing the parameter 
and/or function based at least in part on at least one secure, 
descriptive portion of the component. 

87. A method of performing an electronic transaction 

comprising: 

receiving plural components, 

electronically detecting the occurrence of an event, 

detennining, based on the event, a subset of the plural 
received components to process the event, and 

performing, in response to the event, at least one electronic 
process based on the component subset. 

88. A system for performing an electronic transaction 

comprising: 

means for receiving plural components, 



means for electronically detecting the occurrence of an 

event, 

means for determining, based on the event, a subset of the 
plural received components to process the event, and 

means for performing, in response to the event, at least one 
electronic process based on the component subset. 

89. A distributed transaction processing method 

characterized by the following steps: 

receiving a first electronic component at a first location, 
receiving a second electronic component at a second 

location, 

electronically detecting occurrence of an event at the first 
location, 

processing, in response to the event detection, a first 
portion of an electronic transaction at the first location based at 
least in part on the first electronic component, 

securely transmitting at least one signal from the first 
location to the second location, and 

processing at least a second portion of the electronic 
transaction at the second location based at least in part on the 
second electronic component. 
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90. A method as in claim 89 further characterized by: 
sending at least one signal from the second location to the 

first location, and 

performing at least a third portion of the electronic 
transaction at the first location based at least in part on receipt of 
the signal from the second location. 

91. A distributed transaction processing system 
characterized by: 

means at a first location for receiving a first electronic 
component, for electronically detecting occurrence of an event, for 
processing, in response to the event detection, a first portion of an 
electronic transaction at the first location based at least in part 
on the first electronic component, and for securely transmitting 
at least one signal from the first location to a second location; and 

means at the second location for receiving a second 
electronic component, and for processing at least a second portion 
of the electronic transaction based at least in part on the second 
electronic component. 

92. A system as in claim 91 further characterized by: 
means at the second location for sending at least one signal 
from the second location to the first location, and 



means at the first location for performing at least a third 
portion of the electronic transaction at the first location based at 
least in part on receipt of the signal from the second location. 

93. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that each node can perform 
electronic processes in response to receipt and assembly of 
electronic components, and the node authenticates each of the 
electronic components before assembling them. 

94. A distributed electronic rights management method 
comprising: 

performing, with at least one protected processing 
environment, electronic processes in response to receipt and 
assembly of electronic components, and 

authenticating, within the protected processing 
environment, each of the electronic components before 
assembling them. 

95. A method as in claim 94 wherein the authenticating 
step includes the step of obtaining a corresponding certificate 
from a certifying authority. 



WUWZ7139 



96. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that each node can perform 
electronic processes in response to receipt and assembly of 
electronic components, and the node authenticates each of the 
electronic components by obtaining a corresponding certificate 
from a certifying authority. 

97. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a certifying authority that issues certificates 
allowing each node to authenticate electronic components before 
assembling them to perform and/or control electronic rights 
management processes. 

98. In a distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, a method characterized by the step of issuing 
certificates allowing each node to authenticate electronic 
components before assembling them to perform and/or control 
electronic rights management processes. 

99. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that said nodes enforce usage 



and/or access controls and is capable of electronically obtaining 
compensation from a user and/or other processing of usage 
information for subsequent transfer to rights holders. 

100. In a distributed electronic rights management system 
comprising plural nodes having a protected processing 
environment, a method characterized by the step of enforcing 
usage and/or access controls and electronically obtaining 
compensation from a user and/or other processing of usage 
information for subsequent transfer to rights holders. 

101. A distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, characterized in that each node enforces usage 
and/or access controls based on receipt of information from 
multiple other nodes. 

102. A distributed electronic rights management method 
characterized by the step of enforcing, with a protected 
processing environment, usage and/or access controls based on 
receipt of information from multiple other nodes. 

103. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that said nodes are capable of at 



least temporarily extending electronic credit to an associated 
user for use in compensating rights holders. 

104. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method of operating the environment 
characterized by the step of at least temporarily extending 
electronic credit to an associated user for use in compensating 
rights holders. 

105. A distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, characterized in that said nodes are capable of 
requesting and obtaining a user-specific electronic credit 
assurance from a clearinghouse before granting the user rights to 
access and/or use electronically protected information. 

106. In a distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, a method characterized by the step of requesting 
and obtaining a user-specific electronic credit assurance from a 
clearinghouse before granting the user rights to access and/or use 
electronically protected information. 



107. A distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, characterized in that each node is capable of 
performing and/or requesting an electronic debit or credit 
transaction as a condition to granting the user rights to access 
and/or use electronically protected information. 

108. In a distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, a method characterized by the step of performing 
and/or requesting an electronic debit or credit transaction as a 
condition to granting the user rights to access and/or use 
electronically protected information. 

109. A distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, characterized in that each node can maintain an 
audit trail of user activities for reporting to a centralized location, 
the centralized location analyzing the user activities based on the 
audit trail. 

110. In a distributed electronic rights management system 
comprising plural nodes each having a protected processing 
environment, a method characterized by the steps of: 



Tnni ^ainiTig , a plural locations, audit trails of user 
activities for reporting to a centralized location, and 

analyzing, at the centralized location, the user activities 
based on the audit trail. 

111. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that said node can monitor user 
activities and trigger the occurrence of unrelated events based on 
the user activities and/or the electronic controls that associate 
the user activities with the unrelated events. 

112. A system as in claim 111 wherein the unrelated event 
is activation of an application program. 

113. A system as in claim 111 wherein the unrelated event 
is use of a secure container. 

114. A system as in claim 111 wherein the unrelated event 
is use of the protected processing environment. 

115. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of monitoring 
user activities at said nodes, and triggering the occurrence of 



unrelated events based on the user activities and electronic 
controls that associate the user activities with the unrelated 
events. 

116. A method as in claim 115 wherein the unrelated 
event is at least one of: 

activation of an application program, 

use of a secure container, and 

use of the protected processing environment. 

117. A method of compromising a distributed electronic 
rights management system comprising plural nodes having 
protected processing environments, characterized by the 
following steps: 

exposing a certification private key to allow a person to 
pass a challenge/response protocol, 

defeating at least one of (a) an initialization 
challenge/response security, and/or (b) exposing external 
communication keys, 

creating a processing environment based at least in part on 
the above-mentioned steps, and 

participating in distributed rights management using the 
processing environment. 
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118. A processing environment for compromising a 
distributed electronic rights management system comprising 
plural nodes having protected processing environments, 
characterized by the following: 

means including an exposed certification private key to 
pass a challenge/response protocol, 

means for defeating at least one of (a) an initialization 
challenge/response security, and/or (b) exposing external 
communication keys, and 

means for participating in distributed rights management. 

119. A method of compromising a distributed electronic 
rights management system comprising plural nodes having 
protected processing environments, characterized by the step of 
compromising the permissions record of an electronic container 
and using the compromised permissions record to access and/or 
use electronic information. 

120. A system for compromising a distributed electronic 
rights management system comprising plural nodes having 
protected processing environments, characterized by means for 
using a compromised permissions record of an electronic 
container for accessing and/or using electronic information. 



121. A method of tampering with a protected processing 
environment characterized by the steps of: 

discovering at least one system-wide key, and 
using the key to obtain access to content and/or 
administrative information without authorization. 

122. An arrangement including means for using at least 
one compromised system-wide key to decrypt and compromise 
content and/or administrative information of a protected 
processing environment without authorization. 

123. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that said nodes can electronically 
fingerprint content before releasing it in unprotected form. 

124. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by performing, in at least 
one of the nodes, the step of electronically fingerprinting content 
before releasing it in unprotected form. 

125. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that said nodes can embed, 
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within the electronic content, an electronic fingerprint containing 
specified information identifying a content rights holder and/or 
an indication of origin before including the content in an 
electronic container or allowing access to such content. 

126. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of embedding, 
within electronic content, an electronic fingerprint containing 
specified information, including information identifying a content 
rights holder and/or an indication of origin before including the 
content in an electronic container or allowing access to such 
content. 

127. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that the system includes one or 
more usage clearinghouses that receive usage information from 
one or more of the plural nodes. 

128. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of receiving, 
with a usage clearinghouse, usage information from one or more 
of said plural nodes. 



129. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that the system includes one or 
more financial clearinghouses that receive financial information 
relating to the use of or access to content from one or more of 
nodes. 

130. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of receiving, 
with one or more financial clearinghouses, financial information 
from one or more of the plural nodes. 

131. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that the system includes one or 
more analysis clearinghouses that receive information from one 
or more of the plural nodes and analyzes the received 
information. 

132. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of receiving, 
with one or more analysis clearinghouses, information from one 
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or more of the plural nodes and analyzing the received 
information. 

133. A method of processing information pertaining to the 
use of or access to electronic content wherein such information is 
received from one or more nodes having protected processing 
' environments. 



134. A method of providing credit for interaction with 
content to a protected processing environment node. 

135. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that the system includes one or 
more clearinghouses that transmits rights and/or pennissioning 
information to one or more of the plural nodes. 

136. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of transmitting 
rights and/or peniiissioning information from a clearinghouse to 
one or more of the plural nodes. 



137. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that the system includes one or 
more clearinghouses that periodically transmit cryptographic 
material to one or more of said nodes, the cryptographic material 
renewing and/or replacing expiring cryptographic material. 

138. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the step of periodically 
transmitting cryptographic material from one or more 
clearinghouses to one more of said nodes, the cryptographic 
material renewing and/or replacing expiring cryptographic 
material. 

139. A secure electronic container characterized in that 
the container contains electronic controls for controlling the use 
of and/or access to electronic content that is external to the 
container. 

140. A method comprising: 

accessing electronic controls within a secure electronic 
container; and 
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using the controls for at least in part controlling the use of 
and/or access to electronic content that is external to the 
container. 

141. A secure electronic container characterized in that 
the container contains electronic controls for controlling, at least 
in part, the use of and/or access to distributed electronic content. 

142. A method comprising: 

accessing electronic controls within a secure electronic 
container; and 

using the controls for controlling, at least in part, the use of 
and/or access to distributed electronic content. 



143. A secure electronic container characterized in that 
the container contains electronic controls that cause electronic 
content to expire on a time-dependent basis. 

144. A method for processing a secure electronic container 
including the step of causing, at least in part based on electronic 
controls within the container, electronic content to expire on a 
time-dependent basis. 



145. A method of metering use of and/or access to 
electronic information characterized by the step of maintaining a 
bitmap meter data structure including data partitions that 
subdivide the metering information by time and/or subject 
matter. 

146. A system for metering use of and/or access to 
electronic information characterized by means for maintaining a 
bitmap meter data structure including data partitions that 
subdivide the metering information by time and/or subject 
matter. 

147. A distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, characterized in that the system permits at least 
some of the nodes to securely describe permitted uses of 
electronic content and securely enforces said description. 

148. In a distributed electronic rights management system 
comprising plural nodes having protected processing 
environments, a method characterized by the steps of permitting 
at least some of the nodes to securely describe permitted uses of 
electronic content, and securely enforcing said description. 
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149. A document management system comprising one or 
more electronic appliances containing one or more secure 
processing units and one or more secure databases operatively 
connected to at least one of said secure processing units, said 
system further including protected usage control information 
wherein (a) at least a portion of said control information is 
securely stored within one or more of said secure databases, and 
(b) at least a portion of said control information governs the 
production of usage information, at least a portion of which usage 
information is reported to one or more parties. 

150. In a document management system comprising one or 
more electronic appliances containing one or more secure 
processing units and one or more secure databases operatively 
connected to at least one of said secure processing units, a 
method for processing protected usage control information 
including the steps of securely storing at least a portion of said 
control information within one or more of said secure databases, 
and (b) based at least in part on said control information, 
governing the production of usage information and the reporting 
of at least a portion of said usage information to one or more 
parties. 

151. A document management system comprising plural 
electronic appliances containing protected processing 



environments and one or more secure databases operatively 
connected to at least one of said protected processing 
environments, said system further including protected usage 
control information, wherein (a) at least a portion of said control 
information is securely stored within one or more of said secure 
databases, and (b) at least a portion of said control information 
governs the production of usage information and the reporting of 
at least a portion of said usage information to one or more 
parties. 

152. In a document management system comprising plural 
electronic appliances containing protected processing 
environments and one or more secure databases operatively 
connected to at least one of said protected processing 
environments, a method of handling usage control information 
including the steps of (a) securely storing at least a portion of 
said control information within one or more of said secure 
databases, and (b) governing, based on at least a portion of said 
control information, the production of usage information and the 
reporting of at least a portion of said usage information to one or 
more parties. 

153. An electronic contract system comprising electronic 
appliances containing one or more secure processing units and 
one or more secure databases operatively connected to at least 
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one of the secure processing units, said system furthering 
including means for enabling plural parties to enter into an 
electronic arrangement, at least one of said databases containing 
secure control information for managing at least a portion of a 
plural party electronic arrangement. 

154. In an electronic contract system comprising plural 
electronic appliances containing one or more secure processing 
units and one or more secure databases operatively connected to 
at least one of the secure processing units, a method 
characterized by the steps of enabling plural parties to enter into 
to an electronic arrangement, and using secure control 
information contained by at least one of said databases for 
managing at least a portion of a plural party electronic 
arrangement. 

155. An electronic appliance arrangement containing at 
least one secure processing unit and at least one secure database 
operatively connected to at least one of said secure processing 
unit(s), said arrangement including means to monitor usage of at 
least one aspect of appliance usage and control said usage based 
at least in part upon protected appliance usage control 
information. 



156. In an electronic appliance arrangement containing at 
least one secure processing unit and at least one secure database 
operatively connected to at least one of said secure processing 
unit(s), a method characterized by the steps of monitoring usage 
of at least one aspect of appliance usage and controlling said 
usage based at least in part upon protected appliance usage 
control information. 

157. An electronic appliance arrangement containing a 
protected processing environment and at least one secure 
database operatively connected to said protected processing 
environment, said arrangement including means to monitor 
usage of at least one aspect of an amount of appliance usage and 
control said usage based at least in part upon protected appliance 
usage control information processed at least in part through use 
of said protected processing environment. 

158. In an electronic appliance arrangement containing a 
protected processing environment and at least one secure 
database operatively connected to said protected processing 
environment, a method characterized by the steps of monitoring 
usage of at least one aspect of appliance usage and controlling 
said usage based at least in part upon protected appliance usage 
control information processed at least in part through use of said 
protected processing environment. 
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159. An electronic appliance arrangement containing one 
or more CPUs wherein at least one of the CPUs incorporates an 
integrated secure processing unit, said arrangement storing 
protected appliance usage control information designed to be 
securely processed by said integrated secure processing unit. 

160. In an electronic appliance arrangement containing 
one or more CPUs wherein at least one of the CPUs incorporates 
an integrated secure processing unit, a method including the step 
of storing and securely processing protected modular component 
appliance usage control information with said integrated secure 
processing unit. 

161. An electronic appliance arrangement containing at 
least one first secure processing unit and one or more video 
controllers where at least one of the video controllers 
incorporates at least one second secure processing unit, said 
arrangement storing protected video function control information 
designed to be securely processed by said incorporated secure 
processing unit(s). 

162. In an electronic appliance arrangement containing at 
least one first secure processing unit and one or more video 
controllers where at least one of the video controllers 
incorporates at least one second secure processing unit, the 



method characterized by the step of storing protected video 
function control information designed to be securely processed by 
said incorporated secure processing unites). 

163. An electronic appliance arrangement containing one 
or more video controllers where at least one of the video 
controllers incorporates at least one secure processing unit, said 
arrangement storing protected video function control information 
designed to be securely processed by said incorporated secure 
processing unit(s), wherein at least a portion of said video 
function control information is stored within a secure database 
operatively connected to at least one of said at least one secure 
processing units. 

164. In an electronic appliance arrangement containing 
one or more video controllers where at least one of the video 
controllers incorporates at least one secure processing unit, a 
method including the steps of storing protected video function 
control information designed to be securely processed by said 
incorporated secure processing unit(s), within a database 
operatively connected to at least one of said at least one secure 
processing units. 

165. An electronic appliance arrangement containing one 
or more video controllers and at least one secure processing unit, 
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said arrangement storing component, modular protected video 
function control information designed to be securely processed by 
said secure processing unit(s), wherein at least a portion of said 
video function control information is stored within a secure 
database operatively connected to at least one of said at least one 
secure processing unit(s). 

166. An electronic appliance arrangement containing one 
or more video controllers and at least one secure processing unit, 
a method including the step of storing component, modular 
protected video function control information designed to be 
securely processed by said secure processing unit(s), within a 
secure database operatively connected to at least one of said at 
least one secure processing unit(s). 

167. An electronic appliance arrangement containing at 
least one secure processing unit and one or more network 
communications means where at least one of the network 
communications means incorporates at least one further secure 
processing unit, said arrangement storing protected networking 
control information designed to be processed by said incorporated 
secure processing unit(s). 



168. In an electronic appliance arrangement containing at 
least one secure processing unit and one or more network 



communicationfl means, a method characterized by the steps of 
incorporating, within at least one of the network communications 
means, at least one further secure processing unit, storing 
networking control information at least in part within said 
incorporated secure processing unit(s), and securely processing 
said protected networking control information with said secure 
processing unites). 

169. An electronic appliance arrangement containing one 
or more modems where at least one of the modems incorporates 
at least one secure processing unit, said arrangement storing 
modular, component protected modem control information 
designed to be securely processed by said incorporated secure 
processing unit(s). 

170. In an electronic appliance arrangement containing 
one or more modems where at least one of the modems 
incorporates at least one secure processing unit, a method 
characterized by the step of storing and securely processing 
modular, component protected modem control information with 
said incorporated secure processing unit(s). 



171. An electronic appliance arrangement containing at 
least one secure processing unit and one or more modems where 
at least one of the modems includes at least one farther secure 
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processing unit, said arrangement storing protected modem 
control information designed to be securely processed by said 
included secure processing unit(s). 

172. In an electronic appliance arrangement containing at 
least one secure processing unit and one or more modems where 
at least one of the modems includes at least one further secure 
processing unit, a method including the step of storing and 
securely processing protected modem control information within 
said included secure processing unit(s). 

173. An electronic appliance arrangement containing at 
least one secure processing unit and one or more CD-ROM 
devices where at least one of the CD-ROM devices incorporates at 
least one further secure processing unit, said arrangement 
storing protected CD-ROM control information designed to be 
securely processed by said incorporated secure processing unit(s). 



174. In an electronic appliance arrangement containing at 
least one secure processing unit and one or more CD-ROM 
devices where at least one of the CD-ROM devices incorporates at 
least one further secure processing unit, a method characterized 
by the step of storing and securely processing protected CD-ROM 



control information within said incorporated secure processing 
unit(s). 

175. An electronic appliance arrangement containing one 
or more network communications means where at least one of the 
network communications means incorporates at least one secure 
processing unit, said arrangement storing modular, component,, 
protected networking control information designed to be securely 
processed by said incorporated secure processing unites). 

176. In an electronic appliance arrangement containing 
one or more network communications means where at least one 
of the network communications means incorporates at least one 
secure processing unit, a method characterized by the step of 
storing and securely processing protected networking control 
information with said incorporated secure processing unit(s). 

177. A set-top controller arrangement containing a 
protected processing environment and a database operatively 
connected to said protected processing environment, said 
arrangement further containing control information for 
controlling usage of said controller based upon processing of at 
least a portion of said control information within said protected 
processing environment, wherein at least a portion of said control 
information is stored within said database. 
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178. In a set-top controller arrangement containing a 
protected processing environment and a database operatively 
connected to said protected processing environment, a method 
characterized by the step of: (a) using control information within 
the set-top controller arrangement for controlling usage of said 
controller based upon processing of at least a portion of said 
control information within said protected processing 
environment, and storing at least a portion of said control 
information within said database. 

179. An electronic game arrangement containing a 
protected processing environment for controlling the use of 
electronic games, said arrangement including game usage control 
information, database means operatively connected to said 
protected processing environment for, at least in part, storing 
usage control information for regulating at least some aspect of 
use of at least a portion of at least one of said games, and 
traveling objects containing protected electronic game content. 

180. In an electronic game arrangement containing a 
protected processing environment for controlling the use of 
electronic games, a method including the steps of: 

(a) including game usage control information within a 
database means operatively connected to said protected 
processing environment; and 



(b) regulating, at least in part with the stored usage control 
information, at least some aspect of use of at least a portion of at 
least one of said games. 

181. A method as in claim 178 further including the step of 
regulating the use of traveling objects containing protected 
electronic game content. 



182. An electronic game arrangement containing 
interoperable protected processing environments for controlling 
the use of interactive games, said arrangement including 
protected game usage control information, and database means 
operatively connected to said protected processing environments 
for, at least in part, storing game usage control information. 



183. In an electronic game arrangement containing 
protected processing environments, a method comprising: 

(a) storing, within a secure database means operatively 
connected to said protected processing environments protected 
game usage control information; and 

(b) controlling the use of interactive games based at least 
in part on the storing game usage control information. 



184. An electronic game arrangement containing 
interoperable protected processing environments for controlling 
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the use of games, said arrangement including component, 
modular, protected game usage control information, wherein at 
least a portion of said protected control information was provided 
independently by plural parties securing their respective rights 
in at least one electronic value chain. 

185. In an electronic game arrangement containing 
interoperable protected processing environments for controlling 
the use of games, a method including the steps of: 

(a) providing at least a portion of component, modular, 
protected game usage control information independently by 
plural parties; and 

(b) using the control information at least in part to 
securing respective rights of said plural parties in at least one 
electronic value chain. 

186. An electronic multimedia arrangement containing 
protected processing environments for controlling the use of 
multimedia, said arrangement including component, modular 
multimedia usage control information and database means 
operatively connected to said protected processing environments 
for, at least in part, storing multimedia usage control 
information. 
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187. In an electronic multimedia arrangement containing 
protected processing environments for controlling the use of 
multimedia, a method including the steps of storing multimedia 
usage control information within a database means operatively 
connected to said protected processing environments, and using 
the stored control information to control multimedia. 

188. An electronic multimedia arrangement containing a 
protected processing environment for controlling the use of 
multimedia, said arrangement including multimedia usage 
control information, database means operatively connected to 
said protected processing environment for, at least in part, 
storing multimedia usage control information, and protected 
traveling objects containing distributed multimedia electronic 
content. 

189. In an electronic multimedia arrangement containing 
a protected processing environment, a method characterized by 
the steps of storing multimedia usage control information within 
a database means operatively connected to said protected 
processing environment, and controlling, based at least in part on 
the stored information, protected traveling objects containing 
distributed multimedia electronic content. 
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190. An electronic multimedia arrangement containing 
interoperable protected processing environments for controlling 
the use of multimedia, said arrangement including component, 
modular, protected multimedia usage control information, 
wherein at least a portion of said protected control information 
was provided independently by plural parties securing then- 
respective rights in at least one electronic value chain. 

191. A system as in claim 188 further including a secure 
processing unit. 

192. In an electronic multimedia arrangement containing 
protected processing environments, a method comprising 
providing at least a portion of component, modular, protected 
multimedia usage control information independently by plural 
parties securing their respective rights in at least one electronic 
value chain, and using the usage control information to control 
the use of multimedia. 

193. A method as in claim 190 wherein the using step is 
performed at least in part within a secure processing unit. 

194. An integrated circuit supporting multiple encryption 
algorithms comprising at least one microprocessor, memory, 
input/output means, at least one circuit for encrypting and/or 
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decrypting information and one or more software programs for 
use with at least one of the microprocessors to perform encryption 
and/or decryption functions. 

195. In a secure integrated circuit supporting multiple 
encryption algorithms comprising at least one microprocessor, 
memory, input/output means, and providing a protected 
processing environment, a method characterized by executing at 
least a portion of one or more software programs with the 
microprocessor to perform encryption and/or decryption functions 
within the integrated circuit. 

196. An integrated circuit comprising at least one 
microprocessor, memory, at least one real time clock, at least one 
random number generator, at least one circuit for encrypting 
and/or decrypting information and independently delivered 
and/or independently deliverable certified software. 

197. An integrated circuit comprising at least one 
microprocessor, memory, input/output means, a tamper resistant 
barrier and at least a portion of a Rights Operating System. 

198. An integrated circuit comprising at least one 
microprocessor, memory, input/output means, at least one real 
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time clock, a tamper resistant barrier and means for recording 
interruption of power to at least one of the real time clocks. 

199. A method of distributing information characterized by 
the steps of compressing information, encrypting the compressed 
information at the first location, distributing the encrypted 
information to one or more second locations, using a tamper 
resistant integrated circuit to first decrypt and then decompress 
the information. 

200. A system for distributing information characterized 

by: 

means for compressing information, 
means for encrypting the compressed information at the 
first location, 

means for distributing the encrypted information to one or 
more second locations, and 

means for using a tamper resistant integrated circuit to 
first decrypt and then decompress the information. 

201. A method of securely managing distributed events 
characterized by the steps of providing secure event processing 
environments to one or more users, enabling a first user to 
specify control information for event management through the 
use of a first secure event processing environment, and managing 



the processing of such an event through the use of a second 
secure event processing environment. 

202. A system for securely managing distributed events 
characterized by: 

a first secure event processing environment for enabling a 
first user to specify control information for event management, 
and 

a second secure event processing environment 
interoperable with the first event processing environment for 
managing the processing of such an event. 

203. A method for enabling electronic commerce chain of 
handling and control characterized by the step of a first and a 
second party independently specifying protected, modular 
component control information describing requirements related 
to the operation of an electronic commerce value chain. 

204. A system for enabling electronic commerce chain of 
handling and control characterized by means for permitting a 
first and a second party to independently specify protected, 
modular component control information describing requirements 
related to the operation of an electronic commerce value chain of 
handling and control, and means for securely enforcing the 
requirements described by the control information. 
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205* A method for enabling electronic commerce 
characterized by the step of a first and a second party 
independently stipulating control information managing the use 
of digital information, wherein said first and said second party 
independently maintain persistent rights enforced by said control 
information as said digital information moves through a chain of 
hfm dlrng and control. 

206. A system for enabling electronic commerce including: 
means for allowing a first party to stipulate control 

information managing the use of digital information, 

means for allowing a second party to stipulate control 

information managing the use of the digital information, and 
chain of handling and control means for maintaining 

persistent rights enforced by said control information as said 

digital information moves from one location and/or process to 

another. 

207. A method for secure maintenance of electronic rights 
comprising a first step of plural parties in a value chain 
independently and securely stipulating control information 
regarding their electronic rights, wherein said control 
information is used to enforce conditions related to the use of 
electronic information distributed in software containers. 



208. A system for secure maintenance of electronic rights 
comprising: 

means permitting plural parties in a value chain to 
independently and securely stipulates control information 
regarding their electronic rights, and 

means for using said control information to enforce 
conditions related to the use of electronic information distributed 
in software containers. 

209. A method for securely controlling the use of protected 
electronic content including the step of supporting modular 
separate control information arrangements for managing at least 
one event related to use of said content such that a user may 
select between separate control information arrangements for 
managing such at least one event. 

210. A system for securely controlling the use of protected 
electronic content including modular separate control 
information arrangements for managing at least one event 
related to use of said content such that a user may select between 
separate control information arrangements for managing such at 
least one event. 

211. A method employing separate, modular control 
structures for managing the use of encrypted digital information 
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characterized by the step of enabling commercial value chain 
participants to support plural relationships between two or more 
of: (1) content event triggering, (2) auditing, and (3) budgeting, 
control variables. 

212. A system for employing separate, modular control 
structures for managing the use of encrypted digital information 
characterized by means for enabling commercial value chain 
participants to support plural relationships between two or more 
of: (1) content event triggering, (2) auditing, and (3) budgeting, 
control variables. 

213. A method of chain of handling and control enabling a 
party not directly participating in an electronic value chain to 
contribute secure control information to enforce at least one 
control requirement, said method characterized by a first step of 
a first value chain participant stipulating control information 
associated with digital information and a second step wherein 
said not directly participating party independently and securely 
contributes secure control information for inclusion in an 
aggregate control information set including said associated 
control information, said aggregate control information at least in 
part managing conditions related to the use of at least a portion 
of said digital information by a second value chain participant. 



214. A chain of handling and control system for enabling a 
party not directly participating in an electronic value chain to 
contribute secure control information to enforce at least one 
control requirement, said system characterized by: 

means for allowing a first value chain participant to 
stipulate control information associated with digital information, 

means for allowing the not directly participating party to 
independently and securely contribute secure control information 
for inclusion in an aggregate control information set including 
said associated control information, 

and means responsive to said aggregate control 
information for at least in part managing conditions related to 
the use of at least a portion of said digital information by a 
second value chain participant. 

215. A method of electronic commerce control information 
management for delegating the administration of certain rights 
held by a value chain parly to a second value chain party 
characterized by the step of said first party stipulating secure 
control information describing at least a portion of their rights 
related to one or more chain of handling and control electronic 
events wherein said first party provides further control 
information authorizing said second party to administer some or 
all of said rights as an agent for said first party. 
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216. A system for electronic commerce control information 
management for delegating the administration of certain rights 
held by a value chain party to a second value chain party 
characterized by: 

means for allowing said first party to stipulate secure 
control information describing at least a portion of their rights 
related to one or more chain of handling and control electronic 
events; and 

means for allowing said first party to provide further 
control information authorizing said second party to administer 
some or all of said rights as an agent for said first party. 

217. A method of governing taxation of commercial events 
resulting from electronic chain of h an d l i ng and control 
characterized by a first step of distributing secure digital 
information to a user and specifying secure control information 
controlling at least one condition for use of said digital 
information and a second step of a government agency securely, 
independently contributing secure control information for 
automatically governing tax payments for said commercial 
events. 

218. A system for governing taxation of commercial events 
resulting from electronic chain of handling and control 
characterized by: 



means for distributing secure digital information to a user; 

means for specifying secure control information controlling 
at least one condition for use of said digital information; and 

means for allowing a government agency to securely, 
independently contribute secure control information for 
automatically governing tax payments for said commercial 
events. 

219. A method of governing privacy rights related to 
electronic events characterized by a first step of a first party 
protecting digital information containing information descriptive 
of preventing a second party from at least one unauthorized use 
and a second step of specifying certain control information 
related to use of at least a portion of said protected digital 
information, wherein said control information enforces at least 
one right of said second party related to privacy and/or permitted 
use(s) of personal and/or proprietary information included in said 
protected digital information. 

220. A system for governing privacy rights related to 
electronic events characterized by: 

means for permitting a first party to protect digital 
information containing information descriptive of preventing a 
second party from at least one unauthorized use; 



means for specifying certain control information related to 
use of at least a portion of said protected digital information; and 

means for using the control information to enforce at least 
one right of said second party related to privacy and/or permitted 
use(s) of personal and/or proprietary information included in said 
protected digital information. 

221. A method of governing privacy rights related to 
electronic events characterized by a first step of a first party 
protecting digital information from at least one unauthorized use 
and stipulating certain control information for establishing 
conditions for use of said protected information and a second step 
of a user of said digital information stipulating further control 
information regulating the reporting of information regarding 
said user's use of at least a portion of said digital information. 

222. A system for governing privacy rights related to 
electronic events characterized by: 

means for allowing a first party to protect digital 
information from at least one unauthorized use and for 
stipulating certain control information for establishing conditions 
for use of said protected information; and 

means for allowing a user of said digital information to 
stipulate further control information regulating the reporting of 



information regarding said user's use of at least a portion of said 
digital information. 

223. A secure method for regulating electronic conduct and 
commerce characterized by a step of distributing interoperable 
protected processing environments and circulating amongst 
plural recipients of said protected processing environments 
software containers containing digital content and related 
content control information prepared for use by at least a portion 
of said protected processing environments, wherein said method 
includes the further step of regulating the use at least some of 
said digital content based, at least in part, on the secure 
processing of at least a portion of said control information 
through the use of at least one protected processing environment. 



224. A secure system for regulating electronic conduct and 
commerce characterized by: 

distributed interoperable protected processing 
environments, 

means for circulating, amongst said protected processing 
environments, software containers containing digital content and 
related content control information prepared for use by at least a 
portion of said protected processing environments, and 

means within at least some of the protected processing 
environments for regulating the use at least some of said digital 
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content based, at least in part, on the secure processing of at 
least a portion of said control information. 

225. A method of electronic commerce networking for 
enabling a secure electronic retail environment characterized by 
the step of supplying user certified control information, smart 
cards, secure processing units, and retailing terminal 
arrangements networked together using VDE communication 
techniques and secure software containers. 

226. An electronic commerce networking system for 
enabling a secure electronic retail environment characterized by: 

means for networking together smart cards, secure 
processing units, and retailing terminal arrangements; and 

means for making the smart cards, secure processing units, 
and retailing terminal arrangements interoperable with one 
another and with VDE communication techniques and secure 
software containers. 

227. A method of enabling electronic commerce appliances 
for securely administering user rights in commerce activities 
characterized by the step of providing to users at least a portion 
of a VDE node contained within a physical device, said device 
being configured to be compatible with mating connectors in host 



systems for supporting secure, interoperable transaction activity 
between plural parties. 

228. A system for securely administering user rights in 
commerce activities comprising a physical device including at 
least a portion of a portable VDE node, said device being 
configured to be compatible with mating connectors in host 
systems for supporting secure, interoperable transaction activity 
between plural parties. 

229. A method for enabling a programmable, electronic 
commerce environment characterized by the step of providing to 
multiple parties secure commerce nodes that securely process 
separate, modular component billing management methods, 
budgeting management methods, metering management 
methods, and related auditing management methods and further 
characterized by the step of supporting triggering of metering, 
auditing, billing, and budgeting methods in response to electronic 
commerce event activities. 

230. A programmable, electronic commerce environment 
characterized by secure commerce nodes each including: 

means for securely processing separate, modular 
component billing management methods, budgeting management 



methods, metering management methods, and related auditing 
management methods, and 

means for supporting triggering of metering, auditing, 
billing, and budgeting methods in response to electronic 
commerce event activities. 

231. An electronic commerce system including modular, 
standardized control components comprising electronic commerce 
event control instructions stipulated hy commerce participants, 
and plural electronic appliances containing one or more secure 
processing units which process at least a portion of such 
commerce event control instructions, said system further 
containing one or more databases, operatively connected to at 
least one of the secure processing units, for at least in part 
securely storing at least a portion of such control instructions for 
use by said at least one secure processing unit. 

232. In an electronic commerce system including modular, 
standardized control components comprising electronic commerce 
event control instructions stipulated by commerce participants, 
and plural electronic appliances containing one or more secure 
processing units which process at least a portion of such 
commerce event control instructions, a method characterized by 
the step of providing one or more secure databases, operatively 
connected to at least one of the secure processing units, and at 
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least in part securely storing, within the secure databases, at 
least a portion of such control instructions for use by said at least 
one secure processing unit. 

233. A content distribution system comprising plural 
electronic appliances containing one or more interoperable secure 
processing units operatively connected to one or more databases 
for use with at least one of said secure processing units, said one 
or more databases containing (a) one or more decryption keys for 
use in decrypting distributed, encrypted digital information, and 
(b) encrypted audit information, said audit information reflecting 
at least one aspect of use of said distributed digital information 

234. A content distribution method comprising: 
distributing plural electronic appliances containing one or 

more interoperable secure processing units 

operatively connecting the appliances to one or more 
databases, 

storing within said one or more databases one or more 
decryption keys, 

using the decryption keys for decrypting distributed, 
encrypted digital information, and 

storing within the one or more databases encrypted audit 
information, said audit information reflecting at least one aspect 
of use of said distributed digital information. 
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235. An electronic currency system comprising plural, 
electronic appliances containing (a) protected processing 
environments, (b) encrypted electronic currency and related 
secure control information configured so as to be useable by at 
least one of said protected processing environments, and (c) 
usage reporting means for securely communicating electronic 
currency usage related information from a first interoperable 
protected processing environment to a second interoperable 
protected processing environment. 

236. An electronic currency method comprising: 
distributing plural, electronic appliances containing (a) 

protected processing environments, (b) encrypted electronic 
currency and related secure control information configured so as 
to be useable by at least one of said protected processing 
environments, and 

securely communicating electronic currency usage related 
information from a first interoperable protected processing 
environment to a second interoperable protected processing 
environment. 

237. A method for electronic financial activities 
characterized by the steps of: 



communicating digital containers containing 
financial information from a first interoperable 
secure node to a second interoperable secure node, 
communicating modular, standard control 
information to said second secure node to, at least in 
part, set the conditions for use of at least a portion of 
said financial information, 

reporting information related to said use to said first 
interoperable secure node. 



238. A system for electronic financial activities 
characterized by: 

means for communicating digital containers containing 
financial information from a first interoperable secure node to a 
second interoperable secure node, 

means for communicating modular, standard control 
information to said second secure node, 
means at the second node for, at least in part, setting the 
conditions for use of at least a portion of said financial 
information, and 

means for reporting information related to said use from 
the second secure node to said first interoperable secure node. 

239. A method for electronic currency management 
including: 



communicating encrypted electronic currency from a first, 
interoperable secure user node to a second interoperable user 
node using at least one secure container, and 

providing secure control information for use with said at 
least one secure container, said secure control information, at 
least in part, maintaining conditionally anonymous currency 
usage information* 

240. A system for electronic currency management 
including: 

means for communicating encrypted electronic currency 
from a first, interoperable secure user node to a second 
interoperable user node using at least one secure container, and 

means for providing secure control information for use with 
said at least one secure container, said secure control 
information, at least in part, maintaining conditionally 
anonymous currency usage information. 

241. A method for electronic financial activities 
management characterized by the steps of: 

securely communicating from a first secure node to a 
second secure node financial information standardized control 
information for controlling the use of financial information used 
in a financial value chain, 



securely communicating from said first secure node to a 
third secure node said financial information standardized control 
information for controlling the use of financial information used 
in a financial value chain, 

securely communicating encrypted financial information 
from said second secure node to said third secure node, including 
communicating secure control information, 
processing said financial information at said third node at least 
in part through the use of secure control information supplied by 
said first and said second secure nodes, wherein said 
standardized control information is at least in part stored in a 
secure database contained within said third secure node. 

242. A system for electronic financial activities 
management characterized by the steps of: 

means coupled to a first and a second secure node for 
securely communicating from said first secure node to said 
second secure node financial information standardized control 
information for controlling the use of financial information used 
in a financial value chain, 

means coupled between the first secure node and a third 
secure node for securely communicating from said first secure 
node to said third secure node said financial information 
standardized control information for controlling the use of 
financial information used in a financial value chain, 
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means coupled between the second and third nodes for 
securely communicating encrypted financial information from 
said second secure node to said third secure node, including 
communicating secure control information, and 

means at the third node for processing said financial 
information at said third node at least in part through the use of 
secure control information supplied by said first and said second 

secure nodes, and 

a secure database at the third node for at least in part 
storing said standardized control information. 

243. A method of information management characterized 
by the steps of creating at least one smart object at a first 
location, protecting at least a portion of said smart object 
including protecting at least one rule and/or control assigned to 
said smart object, distributing said at least one smart object to at 
least one second location, securely processing at least a portion of 
the contents of said at least one smart object at said at least one 
second location in accordance with at least a portion of at least 
one said rule and/or control assigned to said smart object. 

244. An information management system characterized 

by: 

means for creating at least one smart object at a first 
location, 
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means for protecting at least a portion of said smart object 
including means for protecting at least one rule and/or control 
assigned to said smart object, 

means for distributing said at least one smart object to at 
least one second location, and 

means for securely processing at least a portion of the 
contents of said at least one smart object at said at least one 
second location in accordance with at least a portion of at least 
one said rule and/or control assigned to said smart object. 

245. An object processing system comprising at least one 
secure object containing at least in part protected executable 
content and at least one at least in part protected rule and/or 
control associated with operations related to the execution of 
such content, and at least one secure execution environment for 
processing the executable content in accordance with at least a 
portion of at least one of said at least one associated rule and/or 
control. 

246. An object processing method comprising: 
providing at least one secure object containing at least in 

part protected executable content and at least one at least in part 
protected rule and/or control associated with operations related 
to the execution of such content, 
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processing, within at least one secure execution 
environment, the executable content in accordance with at least a 
portion of at least one of said at least one associated rule and/or 
control. 

247. A rights distributed database environment including 
(a) means allowing one or more central authorities to establish 
control information for use of encrypted digital information, (b) 
interoperable database management systems at plural user sites 
for securely storing control information and audit information, (c) 
secure communication means for securely communicating control 
information and audit information between user sites, and (d) 
centralized database means for compiling and analyzing usage 
information from plural user sites. 

248, Within a rights distributed database environment, a 
method characterized by the following steps: 

establishing control information for use of encrypted digital 

information, 

securely storing, within interoperable database 
management systems at plural user sites, control information 
and audit information, 

securely communicating control information and audit 
information between user sites, and 



compiling and analyzing usage information from plural 
user sites. 

249. A method of distributed database searching 
characterized by the steps of creating at least one secure object 
containing search criteria, transmitting at least one such secure 
object to one or more second locations to perform database 
searches in accordance with at least one rule and/or control, 
processing at least one database search based at least in part on 
the search criteria within a secure object in accordance with at 
least a portion of at least one of the said at least one associated 
rule and/or control, storing database search results in the same 
and/or one or more new secure objects, and transmitting the 
secure object containing search results to the first location. 

250. A method as in claim 247 further characterized by the 
additional step of associating at least one additional rule and/or 
control with the search results for establishing at least one 
condition related to the use of at least one portion of said search 
results. 

251. A system for distributed database searching 
characterized by: 

means for creating at least one secure object containing 
search criteria, 
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means for transmitting at least one such secure object to 
one or more second locations to perform database searches in 
accordance with at least one rule and/or control, 

means for processing at least one database search based at 
least in part on the search criteria within a secure object in 
accordance with at least a portion of at least one of the said at 
least one associated rule and/or control, 

means for storing database search results in the same 
and/or one or more new secure objects, and 

means for transmitting the secure object containing search 
results to the first location. 

252. A system as in claim 249 further characterized by 
means for associating at least one additional rule and/or control 
with the search results for establishing at least one condition 
related to the use of at least one portion of said search results. 

253. A rights management system comprising protected 
information, at least two protected processing arrangements, and 
a rights management language that allows the expression of 
permitted operations and the consequences of performing such 
operations on at least a portion of the information processed at 
least in part by at least one of the protected processing 
arrangements. 



254. A rights management method comprising: 
providing protected information for processing by at least 

two protected processing arrangements, and 

expressing, in a rights management language, permitted 
operations and the consequences of performing such operations 
on at least a portion of the information processed at least in part 
by at least one of the protected processing arrangements. 

255. A method of protecting digital information 
characterized by the steps of encrypting at least a portion of the 
information, using a rights management language to describe the 
conditions related to use of the information, distributing at least 
a portion of such information and at least a portion of such rights 
language expressed conditions to one or more recipients, using an 
electronic appliance arrangement including at least one protected 
processing arrangement to securely govern at least a portion of 
the use of such information. 

256. A system for protecting digital information 
characterized by: 

means for encrypting at least a portion of the information, 
means for using a rights management language to describe 
the conditions related to use of the information, 
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means for distributing at least a portion of such 
information and at least a portion of such rights language 
expressed conditions to one or more recipients, and 

an electronic appliance arrangement including at least one 
protected processing arrangement for securely governing at least 
a portion of the use of such information. 

257. A distributed digital information management system 
comprising software components, a rights management language 
for expressing processing relationships between two or more of 
the software components, protected processing means for at least 
a portion of the software components and at least a portion of the 
rights management expressions, means for protecting content, 
means for creating software objects that relate protected content 
to rights management expressions, and means for delivering 
protected content, rights management expressions, and such 
software objects from a providing location to a user's location. 

258. A distributed digital information management 
method comprising: 

expressing, in a rights management language, processing 
relationships between two or more of the software components, 

processing, within at least one protected environment, at 
least a portion of the software components and at least a portion 
of the rights management expressions, 



protecting content, 

creating software objects that relate protected content to 
rights management expressions, and 

delivering protected content, rights management 
expressions, and such software objects from a providing location 
to a user's location. 

259. An authentication system comprising at least two 
electronic appliances, at least two digital certificates reflecting 
identity information encrypted using different certifying private 
keys where such certificates are stored in a first electronic 
appliance, communications means for transmitting and receiving 
signals between electronic appliances, means for determining 
compromised and/or expired certifying private keys operatively 
connected to a second electronic appliance, means for the second 
electronic appliance to request transmission of one of the digital 
certificates from the first electronic appliance based at least in 
part on such determination, and means operatively connected to 
such second electronic appliance for decrypting such certificate 
and determining such certificate's validity and/or the validity of 
identity information. 

260. In a system comprising at least two electronic 
appliances, an authenticating method comprising: 



issuing at least two digital certificates reflecting 
identification information, including the step of encrypting the 
two certificates using different certifying private keys, 

storing the certificates in a first electronic appliance, 
transmitting and receiving signals between electronic 
appliances, 

determining compromised and/or expired certifying private 
keys operatively connected to a second electronic appliance, 

requesting, with the second electronic appliance, 
transmission of one of the digital certificates from the first 
electronic appliance based at least in part on such determination, 

decrypting such certificate with the second electronic 
appliance, and 

determining such certificate's validity and/or the validity of 
identity information. 

261. An authentication system comprising at least two 
electronic appliances, at least two digital certificates reflecting 
identify information encrypted using different certifying private 
keys where such certificates are stored in a first electronic 
appliance, communications means for transmitting and receiving 
signals between electronic appliances, means for a second 
electronic appliance to request transmission of one of the digital 
certificates from the first electronic appliance wherein the 
selection of which certificate is requested is based at least in part 



on a random or pseudo-random number, means operatively 
connected to such second electronic appliance for decrypting such 
certificate and determining such certificate's validity and/or the 
validity of identity information* 

262. In a system comprising at least two electronic 
appliances, an authenticating method comprising: 

issuing at least two digital certificates reflecting identify 
information, including the step of encrypting the two digital 
certificates using different certifying private keys, 

storing such certificates in a first electronic appliance, 

transmitting and receiving signals between electronic 
appliances, 

requesting, with a second electronic appliance, 
transmission of one of the digital certificates from the first 
electronic appliance, including the step of selecting a certificate 
based at least in part on a random or pseudo-random number, 

decrypting such certificate with the second electronic 
appliance; and 

determining such certificate's validity and/or the validity of 
identity information. 

263. A method of secure electronic mail characterized by 
the steps of creating at least one electronic message using an 
interoperable protected processing environment, encrypting at 
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least a portion of said at least one message, securely associating 
one or more sets of control information with one or more 
messages to set at least one condition for the use of said at least 
one message, communicating the protected electronic messages to 
one or more recipients having protected processing environments, 
securely communicating at least one set of the same or differing 
control information to each recipient, enabling recipients of both 
control information and protected messages to use message 
information at least in part in accordance with the conditions 
specified by the control information. 

264. A system for secure electronic mail including multiple 
protected processing environments, the system characterized by: 

a first protected processing environment for creating at 
least one electronic message, the first environment including 
means for encrypting at least a portion of said at least one 
message, means for securely associating one or more sets of 
control information with one or more messages to set at least one 
condition for the use of said at least one message, and means for 
communicating the protected electronic messages to one or more 
recipients having interoperable protected processing 

environments, 

means for securely communicating at least one set of the 
same or differing control information to each recipient, and 



means for enabling recipients of both control information 
and protected messages to use message information at least in 
part in accordance with the conditions specified by the control 
information. 

265. A method of information management characterized 
by the steps of protecting content from unauthorized use, 
securely associating enabling control information with at least a 
portion of such protected content wherein such enabling control 
information incorporates information describing how the 
enabling control information may be redistributed, delivering at 
least a portion of the protected content to a first user, delivering 
such enabling control information to such first user, receiving a 
request to redistribute such enabling control information from 
such first user, using the description of how enabling control 
information may be redistributed to create new enabling control 
information where such new enabling control information may be 
the same or different than the enabling control information 
received by such first user, delivering the new enabling control 
information and/or protected information to a second user. 



by: 



266. An information management system characterized 
means for protecting content from unauthorized use, 
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means for securely associating enabling control 
information with at least a portion of such protected content, 
including means for incorporating enabling control information 
describing how the enabling control information may be 
redistributed, 

means for delivering at least a portion of the protected 

content to a first user, 

means for delivering such enabling control information to 

such first user, 

means for receiving a request to redistribute such enabling 
control information from such first user, 

means for using the description of how enabling control 
information may be redistributed to create new enabling control 
information where such new enabling control information may be 
the same or different than the enabling control information 
received by such first user, and 

means for delivering the new enabling control information 
and/or protected information to a second user. 

267. A method of controlling redistribution of distributed 
digital information including the steps of encrypting digital 
information, distributing said encrypted digital information from 
a first party to a second party, establishing control information 
regarding the redistribution of at least a portion of said encrypted 
digital information from said second party to at least one third 



party, regulating the redistribution of said at least a portion of 
said encrypted digital information through the use of a protected 
processing environment processing said control information. 

268. A system for controlling redistribution of distributed 
digital information including: 

means for encrypting digital information, 

means for distributing said encrypted digital information 

from a first party to at least one second party, 

means for establishing control information regarding the 

redistribution of at least a portion of said encrypted digital 

information from said second party to at least one third party, 

and 

a protected processing environment for processing said 
control information and for regulating the redistribution of said 
at least a portion of said encrypted digital information. 

269. A method of controlling a robot characterized by the 
steps of creating instructions for one or more robots, creating a 
secure container incorporating such instructions, associating 
control information with such secure container, incorporating at 
least one secure processing unit into such one or more robots, and 
performing at least a portion of such instructions in accordance 
with at least a portion of such control information. 
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270. A method as in claim 267 further characterized in 
that such control information includes information describing the 
conditions under which such instructions may be used and the 
nature of audit reports required when such instructions are 
performed. 

271. A robot control system characterized by: 
means for creating instructions for one or more robots, 
means for creating a secure container incorporating such 

instructions, 

means for associating control information with such secure 
container, 

means for incorporating at least one secure processing unit 
into such one or more robots, and 

means for performing at least a portion of such instructions 
in accordance with at least a portion of such control information. 

272. A system as in claim 269 further characterized by 
means for creating such control information, including means for 
describing the conditions under which such instructions may be 
used and the nature of audit reports required when such 
instructions are performed. 

273. A method of detecting fraud in electronic commerce 
characterized by the steps of creating at least one secure 



container, associating control information with such one or more 
containers including control information requiring that audit 
information be collected and transmitted to an auditing party, 
delivering such one or more containers and such control 
information to at least one user, recording information 
identifying each container and each such user, receiving audit 
information, creating a profile of usage based at least in part on 
such received audit information and/or such control information, 
detecting cases where certain audit information differs at least in 
part from such profile of usage. 

274. A system for detecting fraud in electronic commerce 

characterized by 

means for creating at least one secure container, 

means for associating control information with such one or 

more containers including control information requiring that 

audit information be collected and transmitted to an auditing 

party, 

means for delivering such one or more containers and such 
control information to at least one user, 

means for recording information identifying each container 
and each such user, 

means for receiving audit information, 
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means for creating a profile of usage based at least in part 
on such received audit information and/or such control 
information, and 

means for detecting cases where certain audit information 
differs at least in part from such profile of usage. 

275* A method of detecting fraud in electronic commerce 
characterized by the steps of distributing at least in part 
protected digital information to customers, distributing one or 
more rights to use at least a portion of such digital information 
across an electronic network, allowing a customer to use at least 
a part of said at least in part protected digital information 
through the use of a protected processing environment and at 
least one of said one or more distributed lights, detecting 
unusual usage activity related to use of said digital information. 

276. A system for detecting fraud in electronic commerce 

characterized by 

means for distributing at least in part protected digital 

information to customers, 

means for distributing one or more rights to use at least a 
portion of such digital information across an electronic network, 

a protected processing environment for allowing a 
customer to use at least a part of said at least in part protected 
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digital information through at least one of said one or more 
distributed rights, and 

means for detecting unusual usage activity related to use 
of said digital information, 

277. A programmable component arrangement comprising 
a tamper resistant processing environment including a 
microprocessor, memory, a task manager, memory manager and 
external interface controller, means for loading arbitrary 
components at least in part into the memory, means for initiating 
one or more tasks associated with processing such components, 
means for certifying the validity, integrity and/or trustedness of 
such components, means for creating arbitrary components, 
means for associating arbitrary events with such created 
components, means for certifying the validity, integrity and/or 
trustedness of such created components, and means for securely 
delivering such created components. 

278. In a programmable component arrangement 
comprising a tamper resistant processing environment including 
a microprocessor, memory, a task manager, memory manager 
and an external interface controller, a processing method 
characterized by the following steps: 

creating arbitrary components, 

associating arbitrary events with such created components, 



loading the arbitrary components at least in part into the 
memory, 

inttintmg one or more tasks associated with processing 
such loaded components, 

certifying the validity, integrity and/or trustedness of such 
created components, and 

securely delivering such created components. 

279. A distributed, protected, programmable component 
arrangement comprising at least two tamper resistant processing 
environments including a microprocessor, memory, a task 
manager, memory manager and external interface controller, 
means for loading arbitrary components at least in part into the 
memory, means for initiating one or more tasks associated with 
processing such components, and means for certifying the 
validity, integrity and/or trustedness of such components, said 
arrangement further comprising means for creating arbitrary 
components, means for associating arbitrary events with such 
created components, means for certifying the validity, integrity 
and/or trustedness of such created components, means for 
securely delivering such created components between at least two 
of said at least two tamper resistant processing environments. 

280. In a distributed, protected, programmable component 
arrangement comprising at least two tamper resistant processing 
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environments including a microprocessor, memory, a task 
manager, memory manager and external interface controller, a 
method comprising 

creating arbitrary components, 
certifying the validity, integrity and/or trustedness of such 
components, 

loading arbitrary components at least in part into the 
memory, 

initiating one or more tasks associated with processing 
such components, 

associating arbitrary events with such created components, 

and 

securely delivering such created components between at 
least two of said at least two tamper resistant processing 
environments. 

281. An electronic appliance comprising at least one CPU, 
memory, at least one system bus, at least one protected 
processing environment, and at least one of a Rights Operating 
System or Rights Operating System layer associated with a host 
operating system. 

282. An operating system comprising at least one task 
manager, at least one memory manager, at least one input/output 
manager, at least one protected processing environment, means 
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for detecting events, means for associating events with rights 
control functions, means for performing rights control functions 
at least in part within such one or more protected processing 
environments. 

283. In an operating system comprising at least one task 
manager, at least one memory manager, at least one input/output 
manager, at least one protected processing environment, an 
operating method comprising: 

detecting events, 

associating events with rights control functions, and 
performing rights control functions at least in part within 
such one or more protected processing environments. 

284. A method of business automation characterized by 
the steps of creating one or more secure containers including 
accounting and/or other administrative information, associating 
control information with such one or more secure containers 
including a description of (a) the one or more parties to whom the 
container may and/or must be delivered and/or (b) the operations 
that one or more parties may and/or must perform with respect to 
such accounting and/or other administrative information, 
delivering one or more of such containers to one or more parties, 
and enabling the description and/or enforcement of at least a 
portion of such control information prior, during and/or 



subsequent to use of such accounting and/or other administrative 
information by one or more parties. 

285. A method as in claim 282 where such control 
information further includes at least one requirement that audit 
information be collected and delivered to one or more auditing 
parties, and further includes the step of delivering at least a 
portion of such audit information to one or more parties. 

286. A method as in claim 283 where at least a portion of 
such audit information is automatically processed by at least one 
of such auditing parties, and further includes the step of 
transmitting further accounting, administrative and/or audit 
information to one or more parties that may be the same and/or 
differ from the one or more parties from whom audit information 
was received based at least in part on the receipt and/or content 
of such received audit information. 

287. A method as in claim 282 where at least two of such 
parties are associated with different businesses and/or other 
organizations and such control information includes information 
that at least in part describes an accounting, administrative, 
reporting and/or other audit relationship between such 
businesses and/or other organizations. 



288. A method as in claim 282, 283, 284, or 285 where 
some or all of such accounting and/or other administrative 
information is included in such control information. 

289. A business automation system characterized by: 
means for creating one or more secure containers including 

accounting and/or other administrative information, 

means for associating, with such one or more secure 
containers, control information including a description of (a) the 
one or more parties to whom the container may and/or must be 
delivered and/or (b) the operations that one or more parties may 
and/or must perform with respect to such accounting and/or other 
administrative information, 

means for delivering one or more of such containers to one 
or more parties, and 

means for enabling the description and/or enforcement of 
at least a portion of such control information prior, during and/or 
subsequent to use of such accounting and/or other administrative 
information by one or more parties. 

290. A system as in claim 287 where the associating 
means further includes means for associating at least one 
requirement that audit information be collected and delivered to 
one or more auditing parties, and the delivering means includes 



means for delivering at least a portion of such audit information 
to one or more parties. 

291. A system as in claim 288 further including means for 
automatically processing at least a portion of such audit 
information, and the system further includes means for 
transmitting further accounting, administrative and/or audit 
information to one or more parties that may be the same and/or 
differ from the one or more parties from whom audit information 
was received based at least in part on the receipt and/or content 
of such received audit information. 

292. A system as in claim 287 where at least two of such 
parties are associated with different businesses and/or other 
organizations and the associating means includes means for 
generating control information including information that at 
least in part describes an accounting, administrative, reporting 
and/or other audit relationship between such businesses and/or 
other organizations. 

293. A system as in claim 286, 287, 288, or 290 where 
some or all of such accounting and/or other administrative 
information is included in such control information. 



294. A method of distributing content characterized by the 
steps of creating one or more first secure containers, associating 
control information with such first containers including 
information describing the conditions under which some or all of 
the content of such first containers may be extracted, delivering 
at least a portion of such first containers and such control 
information to one or more parties, detecting a request by one or 
more of such parties to extract some or all of the content of such 

. first containers, determining if such request is permitted in whole 
or in part by such control information, to the extent permitted by 
such control information creating one or more second secure 
containers in accordance with such request and such control 
information, associating control information with such one or 
more second secure containers based at least in part on control 
information associated with such first containers. 

295. A system for distributing content characterized by: 
means for creating one or more first secure containers, 
means for associating control information with such first 

containers including information describing the conditions under 
which some or all of the content of such first containers may be 
extracted, 

means for delivering at least a portion of such first 
containers and such control information to one or more parties, 
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means for detecting a request by one or more of such 
parties to extract some or all of the content of such first 
containers, 

means for determining if such request is permitted in 
whole or in part by such control information, to the extent 
permitted by such control information creating one or more 
second secure containers in accordance with such request and 
such control information, and 

means for associating control information with such one or 
more second secure containers based at least in part on control 
information associated with such first containers. 

296. A method of distributing content characterized by the 
steps of creating one or more first secure containers, associating 
control information with such first secure containers including 
information describing the conditions under which such first 
secure containers (a) may in whole or in part be embedded into 
and/or securely associated with one or more second secure 
containers and/or (b) may allow one or more secure containers to 
be in whole or in part embedded into and/or securely associated 
with such first secure containers, delivering at least a portion of 
such first secure containers and such control information to one 
or more parties, detecting a request by one or more of such 
parties or by additional parties to (a) in whole or in part embed 
into and/or securely associate with such first containers one or 
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more second containers and/or (b) in whole or in part embed into 
and/or securely associate with a secure container such first 
secure containers, determining if such request is permitted by 
control information, to the extent permitted by control 
information performing one or more embedding and/or secure 
association operations, to the extent required by control 
information and/or requested by one or more of such parties, 
modifying and/or creating new control information at least in 
part as a consequence of such one or more embedding and/or 
secure association operations. 

297. A system for distributing content characterized by 
means for creating one or more first secure containers, 
means for associating control information with such first 
secure containers including information describing the conditions 
under which such first secure containers (a) may in whole or in 
part be embedded into and/or securely associated with one or 
more second secure containers and/or (b) may allow one or more 
secure containers to be in whole or in part embedded into and/or 
securely associated with such first secure containers, 

means for delivering at least a portion of such first secure 
containers and such control information to one or more parties, 

means for detecting a request by one or more of such 
parties to (a) in whole or in part embed into and/or securely 
associate with such first containers one or more second 
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containers and/or (b) in whole or in part embed into and/or 
securely associate with a secure container such first secure 
containers, and 

means for determining if such request is permitted by 
control information, to the extent permitted by control 
information performing one or more embedding and/or secure 
association operations, to the extent required by control 
information and/or requested by one or more of such parties, 
modifying and/or creating new control information at least in 
part as a consequence of such one or more embedding and/or 
secure association operations. 

298. A method of distributing information characterized by 
the steps of protecting information from unauthorized use, 
associating control information with such protected information, 
delivering at least a portion of such protected information to one 
or more parties using plural pathways, delivering at least a 
portion of such control information to one or more parties using 
the same or different plural pathways, enabling at least one of 
such parties to make at least some use of such protected 
information delivered using a first pathway in accordance with 
control information at least a portion of which is delivered using 
a second pathway. 



299. A method as in claim 296 in which at least one of 
such pathways of delivering protected information and/or control 
information is described by such control information. 

300* A system for distributing information characterized 

by: 

means for protecting information from unauthorized use, 

means for associating control information with such 
protected information, 

means for delivering at least a portion of such protected 
information to one or more parties using plural pathways, 

means for delivering at least a portion of such control 
information to one or more parties using the same or different 
plural pathways, 

means for enabling at least one of such parties to make at 
least some use of such protected information delivered using a 
first pathway in accordance with control information at least a 
portion of which is delivered using a second pathway. 

301. A system as in claim 298 wherein the delivering 
means includes means for delivering, over at least one of such 
pathways, protected information and/or control information 
described by such control information. 





302. A method of distributing information characterized by 
the steps of protecting information from unauthorized use, 
associating control information with such protected information 
including information requiring the collection of audit 
information, enabling one or more parties to receive and/or 
process audit information, delivering at least a portion of such 
protected information and such control information to one or 
more parties, enabling at least some use of such protected 
information in accordance with at least a portion of such control 
information that requires the collection of audit information, 
delivering such audit information to one or more of such enabled 
auditing parties different from such delivering party or parties. 

303. A method as in claim 300 in which at least one of 
such auditing parties is specified in such control information. 

304. A system for distributing information characterized 

by 

means for protecting information from unauthorized use, 
means for associating control information with such 

protected information including information requiring the 

collection of audit information, 

means for enabling one or more parties to receive and/or 

process audit information, 



means for delivering at least a portion of such protected 
information and such control information to one or more parties, 

means for enabling at least some use of such protected 
information in accordance with at least a portion of such control 
information that requires the collection of audit information, and 

means for delivering such audit information to one or more 
of such enabled auditing parties different from such delivering 
party or parties. 

305. A system as in claim 302 in which at least one of such 
auditing parties is specified in such control information. 

306. A secure component-based operating process 

including: 

(a) retrieving at least one component; 

(b) retrieving a record that specifies a component 
assembly; 

(c) checking said component and/or said record for validity; 

(d) using said component to form said component assembly 
in accordance with said record; and 

(e) performing a process based at least in part on said 
component assembly. 

307. A process as in claim 304 wherein said step (c) 
further comprises executing said component assembly. 
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308. A process as in claim 304 wherein said component 
comprises executable code. 

309. A process as in claim 304 wherein said component 
comprises a load module. 

310. A process as in claim 304 wherein: 
said record comprises: 

(i) directions for assembling said component assembly; 
and 

(ii) information that at least in part specifies a control; 
and 

said process further comprises controlling said step (d) 
and/or said step (e) based at least in part on said control. 

311. A process as in claim 304 wherein said component 
has a security wrapper, and said controlling step comprises 
selectively opening said security wrapper based at least in part 
on said control. 

312. A process as in claim 304 wherein: 

said permissions record includes at least one decryption 
key; and 

said controlling step includes controlling use of said 
decryption key. 



313. A process as in claim 304 including performing at 
least two of said steps (a) and (e) within a protected processing 
environment. 

314. A process as in claim 304 including performing at 
least two of said steps (a) and (e) at least in part within tamper- 
resistant hardware. 

315. A method as in claim 304 wherein said performing 
step (e) includes metering usage. 

316. A method as in claim 304 wherein said performing 
step (e) includes auditing usage. 

317. A method as in claim 304 wherein said performing 
step (e) includes budgeting usage. 

318. A secure component operating system process 
including: 

receiving a component; 

receiving directions specifying use of said component to 
form a component assembly; 

authenticating said received component and/or said 
directions; 



forming, using said component, said component assembly 
based at least in part on said received directions; and 

using said component assembly to perform at least one 
operation* 

319. A method comprising performing the following steps 
within a secure operating system environment: 

providing code; 

providing directions specifying assembly of said code into 
an executable program; 

checking said received code and/or said assembly directors 
for validity; and 

in response to occurrence of an event, assembling said code 
in accordance with said received assembly directions to form an 
assembly for execution. 

320. A method for managing at least one resource with a 
secure operating environment, said method comprising: 

securely receiving a first control from a first entity external 
to said operating environment; 

securely receiving a second control from a second entity 
external to said operating environment, said second entity being 
different from said first entity; 

securely processing, using at least one resource, a data 
item associated with said first and second controls; and 
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securely applying said first and second controls to manage 
said resource for use with said data item. 

321. A method for securely managing at least one 
operation on a data item performed at least in part by an 
electronic arrangement, said method comprising: 

(a) securely delivering a first procedure to said electronic 
arrangement; 

(b) securely delivering, to said electronic arrangement, a 
second procedure separable or separate from said first procedure; 

(c) performing at least one operation on said data item, 
including using said first and second procedures in combination 
to at least in part securely manage said operation; and 

(d) securely conditioning at least one aspect of use of said 
data item based on said delivering steps (a) and (b) having 
occurred. 

322. A method as in claim 319 including performing said 
delivering step (b) at a time different from the time said 
delivering step (a) is performed. 

323. A method as in claim 319 wherein said step (a) 
includes delivering said first procedure from a first source, and 
said step (b) includes delivering said second procedure from a 
second source different from said first source. 
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324. A method as in claim 319 further including ensuring 
the integrity of said first and second procedures. 

325. A method as in claim 319 further including validating 
each of said first and second procedures. 

326. A method as in claim 319 further including 
authenticating each of said first and second procedures. 

327. A method as in claim 319 wherein said using step (c) 
includes executing at least one of said first and second procedures 
within a tamper-resistant environment. 

328. A method as in claim 319 wherein said step (c) 
includes the step of controlling said data item with at least one of 
said first and second procedures. 

329. A method as in claim 319 further including 
establishing a relationship between at least one of said first and 
second procedures and said data item. 

330. A method as in claim 319 further including 
establishing correspondence between said data item and at least 
one of said first and second procedures. 
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331. A method as in claim 319 wherein said delivering 
step (b) comprises delivering at least one load module encrypted 
at least in part. 

332. A method as in claim 329 wherein said delivering 
step (a) comprises delivering at least one further load module 
encrypted at least in part. 

333. A method as in claim 319 wherein said delivering 
step (b) comprises delivering at least one content container 
carrying at least in part secure control information. 

334. A method as in claim 319 wherein said delivering 
step (b) comprises delivering a control method and at least one 
further method. 

335. A method as in claim 319 wherein said delivering 
step (a) includes: 

encrypting at least a portion of said first procedure, 

communicating said at least in part encrypted first 
procedure to said electronic arrangement, 

decrypting at least a portion of said first procedure at least 
in part using said electronic arrangement, and 

validating said first procedure with said electronic 
arrangement. 



336. A method as in claim 319 wherein said delivering 
step (b) includes delivering at least one of said first and second 
procedures within an administrative object. 

337. A method as in claim 319 wherein said delivering 
step (b) includes codelivering said second procedure in at least in 
part encrypted form with said data item. 

338. A method as in claim 319 wherein said performing 
step includes metering usage. 

339. A method as in claim 319 wherein said performing 
step includes auditing usage. 

340. A method as in claim 319 wherein said performing 
step includes budgeting usage. 

341. A method for securely managing at least one 
operation performed at least in part by a secure electronic 
appliance, comprising: 

(a) selecting an item that is protected with respect to at 
least one operation; 

(b) securely independently delivering plural separate 
procedures to said electronic appliance; 



(c) using said plural separate procedures in combination to 
at least in part securely manage said operation with respect to 
said selected item; and 

(d) conditioning successful completion of said operation on 
said delivering step (b) having occurred. 

342. A method for processing based on deliverables 
comprising: 

securely delivering a first piece of code defining a first part 
of a process; 

separately, securely delivering a second piece of code 
defining a second part of said process; 

ensuring the integrity of the first and second delivered 
pieces of code; and 

performing said process based at least in part on said first 
and second delivered code pieces. 

343. A method as in claim 340 wherein a first piece of code 
for said process at least in part controls decrypting content. 

344. A method as in claim 340 wherein said ensuring step 
includes validating said first and second pieces of code. 
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345. A method as in claim 340 wherein said ensuring step 
includes validating said first and second pieces of code relative to 
one another. 

346. A method as in claim 340 wherein said performing 
step includes metering usage. 

347. A method as in claim 340 wherein said performing 
step includes auditing activities. 

348. A method as in claim 340 wherein said performing 
step includes budgeting usage. 

349. A method as in claim 340 wherein said performing 
step includes electronically processing content based on electronic 
controls. 

350. A method of securely controlling at least one 
protected operation with respect to a data item comprising: 

(a) supplying at least a first control from a first party; 

(b) supplying at least a second control from a second party 
different from said first party; 

(c) securely combining said first and second controls to 
form a set of controls; 



(d) securely associating said control set with said data 
item; and 

(e) securely controlling at least one protected operation 
with respect to said data item based on said control set. 

351. A method as in claim 348 wherein said data item is 
protected. 

352. A method as in claim 348 wherein at least one of said 
plural controls includes a control relating to metering at least one 
aspect of use of said protected data item. 

353. A method as in claim 348 wherein at least one of said 
plural controls include a control relating to budgeting at least one 
aspect of use of said protected data item. 

354. A secure method for combining data items into a 
composite data item comprising: 

(a) securely providing a first data item having at least a 
first control associated therewith; 

(b) securely providing a second data item having at least a 
second control associated therewith; 

(c) forming a composite of said first and second data 

items; 



(d) securely combining said first and second controls into a 
composite control set; and 

(e) performing at least one operation on said composite of 
said first and second data items based at least in part on said 
composite control set. 

355. A method as in claim 352 wherein said combining 
step includes preserving each of said first and second controls in 
said composite set. 

356. A method as in claim 352 wherein said performing 
step comprises governing the operation on said composite of said 
first and second data items in accordance with said first control 
and said second control . 

357. A method as in claim 352 wherein said providing step 
includes ensuring the integrity of said association between said 
first controls and said first data item is maintained during at 
least one of transmission, storage and processing of said first 
data item. 

358. A method as in claim 352 wherein said providing step 
comprises delivering said first data item separately from said 
first control . 



359. A method as in claim 352 wherein said providing step 
comprises codelivering said first data item and said first control . 

360. A secure method for controlling a protected operation 
comprising: 

(a) delivering at least a first control and a second control; 

and 

(b) controlling at least one protected operation based at 
least in part on a combination of said first and second controls, 
including at least one of the foUowing steps: 

resolving at least one conflict between said first and 
second controls based on a predefined order; 

providing an interaction with a user to form said 
combination; and 

dynamically negotiating between said first and second 

controls. 

361. A method as in claim 358 wherein said controlling 
step (b) includes controlling decryption of electronic content. 

362. A method as in claim 358 further including: 
receiving protected electronic content from a party; and 
authenticating the identity of said party prior to using said 

received protected electronic content. 



363. A secure method comprising: 
selecting protected data; 

extracting said protected data from an object; 
identifying at least one control to manage at least one 
aspect of use of said extracted data; 

placing said extracted data into a further object; and 
associating said at least one control with said further 

object. 

364. A method as in claim 361 further including limiting 
at least one aspect of use of said further object based on said at 
least one control. 

365. A secure method of modifying a protected object 
comprising: 

(a) providing a protected object; and 

(b) embedding at least one additional element into said 
protected object without unprotecting said object. 

366. A method as in claim 60 further including: 
associating at least one control with said object; and 
limiting usage of said element in accordance with said 

control. 



367. A method as in claim 363 further including a 
permissions record within said object. 

368. A method as in claim 364 further including at least in 
part encrypting said object. 

369. A method for managing at least one resource with a 
secure operating environment, said method comprising: 

securely receiving a first load module from a first entity 
external to said operating environment; 

securely receiving a second load module from a second 
entity external to said operating environment, said second entity 
being different from said first entity; 

securely processing, using at least one resource, a data 
item associated with said first and second load modules; and 

securely applying said first and second load modules to 
manage said resource for use with said data item. 

370. A method for negotiating electronic contracts, 
comprising: 

receiving a first control set from a remote site; 
providing a second control set; 

performing, within a protected processing environment, an 
electronic negotiation between said first control set and said 



second control set, including providing interaction between said 
first and second control sets; and 

producing a negotiated control set resulting from said 
interaction between said first and second control sets. 

371. A system for supporting electronic commerce 
including: 

means for creating a first secure control set at a first 
location; 

means for creating a second secure control set at a second 
location; 

means for securely communicating said first secure control 
set from said first location to said second location; and 

means at said second location for securely integrating said 
first and second control sets to produce at least a third control set 
comprising plural elements together comprising an electronic 
value extended agreement. 

372. A system for supporting electronic commerce 
including: 

means for creating a first secure control set at a first 
location; 

means for creating a second secure control set at a second 
location; 



means for securely communicating said first secure control 
set from said first location to said second location; and 

negotiation means at said second location for negotiating 
an electronic contract through secure execution of at least a 
portion of said first and second secure control sets. 

373. A system as in claim 370 further including means for 
controlling use by a user of protected information content based 
on at least a portion of said first and/or second control sets. 

374. A system as in claim 370 further including means for 
charging for at least a part of said content use. 

375. A secure component-based operating system 
including: 

component retrieving means for retrieving at least one 
component; 

record retrieving means for retrieving a record that 
specifies a component assembly; 

checking means, operatively coupled to said component 
retrieving means and said record retrieving means, for checking 
said component and/or said record for validity; 

using means, coupled to said checking means, for using 
said component to form said component assembly in accordance 
with said record; and 



performing means, coupled to said using means, for 
performing a process based at least in part on said component 
assembly. 

376. A secure component-based operating system 
including: 

a database manager that retrieves, from a secure database, 
at least one component and at least one record that specifies a 
component assembly; 

an authenticating manager that checks said component 
and/or said record for validity; 

a channel manager that uses said component to form said 
component assembly in accordance with said record; and 

an execution manager that performs a process based at 
least in part on said component assembly. 

377. A secure component operating system including: 
means for receiving a component; 

means for receiving directions specifying use of said 
component to form a component assembly; 

means, coupled to said receiving means, for authenticating 
said received component and/or said directions; 

means, coupled to said authenticating means, for forming, 
using said component, said component assembly based at least in 
part on said received directions; and 
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means, coupled to said forming means, for using said 
component assembly to perform at least one operation. 

378. A secure component operating environment 
including: 

a storage device that stores a component and directions 
specifying use of said component to form a component assembly; 

an authenticating manager that authenticates said 
component and/or said directions; 

a channel manager that forms, using said component, said 
component assembly based at least in part on said directions; and 

a channel that executes said component assembly to 
perform at least one operation. 

379. A secure operating system environment comprising: 
a storage device that stores code and directions specifying 

assembly of said code into an executable program; 

a validating device that checks said received code and/or 
said assembly directors for validity; and 

an event-driven channel that, in response to occurrence of 
an event, assembles said code in accordance with said assembly 
directions to form an assembly for execution. 

380. A secure operating environment system for managing 
at least one resource comprising: 
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a communications arrangement that securely receives a 
first control from a first entity external to said operating 
environment, and securely receives a second control from a 
second entity external to said operating environment, said second 
entity being different from said first entity; and 

a protected processing environment, coupled to said 
communications arrangement, that: 

(a) securely processes, using at least one resource, a data 
item associated with said first and second controls, and 

(b) securely applies said first and second controls to 
manage said resource for use of said data item. 

381. A system for negotiating electronic contracts, 
comprising: 

a storage arrangement that stores a first control set 
received from a remote site, and stores a second control set; 

a protected processing environment, coupled to said 
storage arrangement, that: 

(a) performs an electronic negotiation between said 
first control set and said second control set, 

(b) provides interaction between said first and 
second control sets, and 

(c) produces a negotiated control set resulting from 
said interaction between said first and second control sets. 



382. A system as in claim 379 further including means for 
electronically enforcing said negotiated control set. 

383. A system as in claim 379 further including means for 
generating an electronic contract based on said negotiated control 
set. 

384. A method for supporting electronic commerce 
including: 

creating a first secure control set at a first location; 

creating a second secure control set; 

electronically negotiating, at said location different from 
said first location, an electronic contract, including the step of 
securely executing at least a portion of said first and second 
control sets. 

385. An electronic appliance comprising: 
a processor; and 

at least one memory device connected to said processor; 
wherein said processor includes: 
retrieving means for retrieving at least one component, 
and at least one record that specifies a component assembly, from 
said memory device, 

checking means coupled to said retrieving means for 
checking said component and/or said record for validity, and 
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using means coupled to said retrieving means for using 
said component to form said component assembly in accordance 
with said record. 

386. An electronic appliance comprising: 
at least one processor, 

at least one memory device connected to said processor; 

and 

at least one input/output connection operatively coupled to 
said processor, 

wherein said processor at least in part executes a rights 
operating system to provide a secure operating environment 
within said electronic appliance. 

387. An electronic appliance as in claim 384 wherein said 
processor includes means for providing a channel, said channel 
assembling independently deliverable components into a 
component assembly and executing said component assembly. 

388. An electronic appliance as in claim 384 further 
including a secondary storage device coupled to said processor, 
said secondary storage device storing a secure database, said 
processor including means for decrypting information obtained 
from said secure database and for encrypting information to be 
written to said secure database. 



389* An electronic appliance as in claim 384 wherein said 
processor and said memory device are disposed in a secure, 
tamper-resistance encapsulation. 

390* An electronic appliance as in claim 384 wherein said 
processor includes a hardware encryptor/decryptor. 

391. An electronic appliance as in claim 384 wherein said 
processor includes a real time clock. 

392. An electronic appliance as in claim 384 wherein said 
processor includes a random number generator. 

393. An electronic appliance as in claim 384 wherein said 
memory device stores audit information. 

394. A method for auditing the use of at least one resource 
with a secure operating environment, said method comprising: 

securely receiving a first control from a first entity external 
to said operating environment; 

securely receiving a second control from a second entity 
external to said operating environment, said second entity being 
different from said first entity; 

using at least one resource; 



securely sending to said first entity in accordance with said 
first control, first audit information concerning use of said 
resource; and 

securely sending to said second entity in accordance with 
said second control, second audit information concerning use of 
said resource, said second audit information being at least in part 
different from said first audit information. 

395. A method for auditing the use of at least one resource 
with a secure operating environment, said method comprising: 

securely receiving first and second control alternatives 
from an entity external to said operating environment; 

selecting one of said first and second control alternatives; 

using at least one resource; 

if said first control alternative is selected by said selecting 
step, securely sending to said entity in accordance with said first 
control alternative, first audit information concerning use of said 
resource; and 

if said second control alternative is selected by said 
selecting step, securely sending to said second entity in 
accordance with said second control alternative, second audit 
information concerning use of said resource, said second audit 
information being at least in part different from said first audit 
information. 
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396. A method and/or system for enabling a sale of 
protected digital information that has been previously distributed 
to users, the method or system being characterized by a secure 
element that selectively controls access to the protected digital 
information based on electronic controls associated with the 
information. 

397. A distributed, secure electronic point of sale system or 
method characterized by a secure processing element for 
selectively releasing goods and/or services in exchange for 
compensation. 

398. In a distributed digital network, an advertising 
method characterized by the steps of tracking usage of digital 
information that has associated with it one or more controls with 
respect to access to and/or usage of said information; and 
targeting advertising messages based at least in part on said 
tracking. 

399. A distributed electronic advertising system 
characterized in that the system uses a distributed network of 
interoperable protected processing environments to at least in 
part deliver advertising to users. 



WUyO/Z7139 

400. A distributed, secure, virtual black box comprised of 
nodes located at VDE content container creators, other content 
providers, client users, and recipients of secure VDE content 
usage information) site, the nodes of said virtual black box 
including a secure subsystem having at least one secure 
hardware element such as a semiconductor element or other 
hardware module for securely executing VDE control processes, 
said secure subsystems being distributed at nodes along a 
pathway of information storage, distribution, payment, usage, 
and/or auditing* 

401. A protected processing system or method providing 
multiple currencies and/or payment arrangements for the secure 
processing and releasing of protected digital information. 

402. A distributed secure method or system characterized 
in that a user's age is used as a criteria for electronically, 
securely releasing information and/or resources to the user. 

403. A method of renting an electronic appliance defining 
a secure processing environment. 

404. A virtual distribution environment providing any one 
or more of the following features and/or elements and/or 
combinations thereof: 



a configurable protected, distributed event management 
system; and/or 

a trusted, distributed transaction and storage management 
arrangement; and/or 

plural pathways for providing information, for control 
information, and/or for reporting; and/or 

multiple payment methods; and/or 

multiple currencies; and/or 

EDI; and/or 

Electronic banking; and/or 
electronic document management; and/or 
electronic secure communication; and/or 
e-mail; and/or 

distributed asynchronous reporting; and/or 

combination asynchronous and online management; and/or 

privacy control by users; and/or 

testing; and/or 

using age as a class; and/or 

appliance control (renting, etc.); and/or 

telecommunications infrastructure; and/or 

games management; and/or 

extraction of content from an electronic container; and/or 
embedding of content into an electronic container; and/or 
multiple certificate to allow for breach of a key; and/or 
virtual black box; and/or 
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independence of control information from content; and/or 
multiple, separate, simultaneous control sets for one digital 

information property; and/or 

updating control information for already distributed digital 

information; and/or 

organization information management; and/or 
coupled external and organization internal chain of 

handling and control; and/or 

a content usage consequence management system 

(reporting, payment, etc., multiple directions); and/or 

a content usage reporting system providing differing audit 

information and/or reduction going to multiple parties holding 

rights in content; and/or 

an automated remote secure object creation system; and/or 
infrastructure background analysis to identify improper 

use; and/or 

seniority of control information system; and/or 

secure distribution and enforcement of rules and controls 

separately from the content they apply to; and/or 

redistribution management by controlling the rights and/or 

number of copies and or pieces etc. that may be redistributed; 

and/or 

an electronic commerce taxation system; and/or 
an electronic shopping system; and/or 
an electronic catalog system; and/or 



a system handling electronic banking, electronic shopping, 
and electronic content usage management; and/or 

an electronic commerce multimedia system; and/or 

a distributed, secure, electronic point of sale system; and/or 

advertising; and/or 

electronics rights management; and/or 

a distributed electronic commerce system; and/or 

a distributed transaction system or environment; and/or 

a distributed event management system; and/or 

a distributed light systems. 

405. A Virtual Distribution Environment substantially as 
shown in Figure 1. 

406. An "Information Utility" substantially as shown in 
Figure 1A. 

407. A chain of handling and control substantially as 
shown in Figure 1. 

408. Persistent rules and control information substantially 
as shown in Figure 2A. 

409. A method of providing diflFerent control information 
substantially as shown in Figure 1. 
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410. Rules and/or control information substantially as 
shown in Figure 4. 

411. An object substantially as shown in Figures 5A and 

5B. 

412. A Secure Processing Unit substantially as shown in 
Figure 6. 

413. An electronic appliance substantially as shown in 
Figure 7. 

414. An electronic appliance substantially as shown in 
Figure 8. 

415. A Secure Processing Unit substantially as shown in 
Figure 9. 

416. A "Rights Operating System" (*ROS w ) architecture 
substantially as shown in Figure 10. 

417. Functional relationship(s) between applications and 
the Rights Operating System substantially as shown in Figures 
11A-11C. 
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418. Components and component assemblies substantially 
as shown in Figures 11D-11J. 

419. A Rights Operating System substantially as shown in 
FIGURE 12. 

420. A method of objection creation substantially as shown 
in Figure 12A. 

421. A protected processing environment" software 
architecture substantially as shown in Figure 13. 

422. A method of supporting a channel substantially as 
shown in Figure 15. 

423. A channel header and channel detail record 
substantially as shown in Figure 15 A. 

424. A method of creating a channel substantially as 
shown in Figure 15B. 

425. A secure data base substantially as shown in Figure 

16. 

426. A logical object substantially as shown in Figure 17. 



427. A stationary object substantially as shown in 
FIGURE 18. 

428. A travelling object substantially as shown in FIGURE 

19. 

429. A content object substantially as shown in FIGURE 

20. 

430. An administrative object substantially as shown in 
Figure 21. 

431. A method core substantially as shown in Figure 22. 

432. A load module substantially as shown in FIGURE 

23. 

433. A User Data Element (UDE) and/or Method Data 
Element (MDE) substantially as shown in FIGURE 24. 

434. Map meters substantially as shown in FIGURES 
25A-25C. 

435. A permissions record (PERC) substantially as shown 
in FIGURE 26. 
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436. A permissions record (PERC) substantially as 
shown in FIGURES 26A and 26B. 

437. A shipping table substantially as shown in FIGURE 

27. 

438. A receiving table substantially as shown in FIGURE 

28. 

439. An administrative event log substantially as shown 
in FIGURE 29. 

440. A method of interrelating and using an object 
registration table, a subject table and a user rights table 
substantially as shown in Figure 30. 

441. A method of using a site record table and a group 
record table to track portions of a secure database substantially 
as shown in FIGURE 34. 

442. A process for updating a secure database 
substantially as shown in FIGURE 35. 

443. A process of inserting new elements into a secure 
database substantially as shown in FIGURE 36. 
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444. A process of accessing elements in a secure database 
substantially as shown in FIGURE 37. 

445. A process of protecting a secure database element 
substantially as shown in FIGURE 38. 

446. A process of backing up a secure database 
substantially as shown in FIGURE 39. 

447. A process of recovering a secure database 
substantially as shown in FIGURE 40. 

448. A process of enabling performing reciprocal methods 
to provide a chain of handling and control substantially as shown 
in FIGURES 41A-41D. 

449. A "reciprocal" BUDGET method substantially as 
shown in FIGURES 42A-42D. 

450. A reciprocol audit method substantially as shown in 
FIGURES 44A-44C. 

451. A method for controlling release of content or other 
method substantially as shown in any of FIGURES 45-48. 



452. An event method substantially as shown in 
FIGURES 53A-53B. 

453. A billing method substantially as shown in FIGURE 

53C. 

454. An extract method substantially as shown in 
FIGURE 57A. 

455. An embed method substantially as shown in FIGURE 

57A. 

456. An obscure method substantially as shown in 
FIGURE 58A. 

457. A fingerprint method substantially as shown in 
FIGURE 58B. 

458. A fingerprint method substantially as shown in 
FIGURE 58C. 

459. A meter method substantially as shown in FIGURE 

6. 
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460. A key "convolution" process substantially as shown in 
FIGURE 62. 

461. A process of generating different keys using a key 
convolution process to determine a "true* key substantially as 
shown in FIGURE 63. 

462. A process of initializing protected processing 
environment keys substantially as shown in FIGURES 64 and/or 
65. 

463. A process for decrypting information contained within 
stationary objects substantially as shown in FIGURE 66. 

464. A process for decrypting information contained within 
traveling objects substantially as shown in FIGURE 67. 

465. A process for initializing a protected processing 
environment substantially as shown in FIGURE 68. 

466. A process of downloading firmware into a protected 
processing environment substantially as shown in FIGURE 69. 



467. Multiple VDE electronic appliances connected together with 
a network or other communications means substantially as 
shown in FIGURE 70. 

468. A portable VDE electronic appliance substantially as 
shown in FIGURE 71. 

469. *Pop-up w displays that may be generated by the user 
notification and exception interface substantially as shown in 
Figures 72A-72D. 

470. A smart object substantially as shown in FIGURE 73. 

471. A method of processing smart objects substantially as 
shown in FIGURE 74. 

472. Electronic negotiation substantially as shown in any 
of FIGURES 75A-75D. 

473. An electronic agreement substantially as shown in 
FIGURES 75E-75F. 



474. Electronic negotiation processes substantially as 
shown in any of FIGURES 76A-76B. 
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475. A chain of handling and control substantially as 
shown in FIGURE 77. 

476. A VDE "repository " substantially as shown in 
FIGURE 78. 

477. A process of using a chain of handling and control to 
evolve and transform VDE managed content and control 
information substantially as shown in any or all of FIGURES 
79-83. 

478. A chain of handling and control involving several 
categories of VDE participants substantially as shown in 
FIGURE 84. 

479. A chain of distribution and handling within an 
organization substantially as shown in FIGURE 85. 

480. A chain of handling and control substantially as 
shown in Figures 86 and/or 86A. 

481. A virtual silicon container model substantially as 
shown in Figure 87. 



482. A method of business automation characterized by 
the steps of (a) creatings one or more secure containers including 
encrypted accounting and/or other administrative information 
content, (b) associating control information with one or more of 
such one or more secure containers including a description of (i) 
the one or more parties whom may use one or more of the one or 
more containers, and (ii) the operations that will be performed for 
one or more parties with respect to such accounting and/or other 
administrative information, (c) electronically delivering one or 
more of such one or more containers such to one or more parties, 
and (d) enabling through the use of a protected processing 
environment the enforcement of at least a portion of such control 
information. 

483. A business automation system characterized by: 
means for providing at least one secure container including 

administrative information content having control information 
associated therewith, and 

a protected processing environment for enforcing, at least 
in part, the control information. 

484. A business automation system comprising (a) 
distributed, interoperable protected processing environment 
installations, (b) secure containers for distribution of digital 

1 ATO 
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information, (c) control information supporting the automation of 
r foftin of handling and control functions. 

485. A method of business automation characterized by 
the steps of providing interoperable protected processing 
environment nodes to plural parties, communicating first 
encrypted digital information from a first party to a second party, 
communicating second encrypted digital information including at 
least a portion of said first communicated digital information 
and/or information related to the use of said first digital 
information, to a third party different from said first or second 
parties, wherein use of said second encrypted digital information 
is regulated, at least in part, by an interoperable protected 
processing environment available to said third party. 

486. A business automation system characterized by: 
plural protected processing environment nodes, 

means for communicating digital information between the 
nodes, and 

wherein at least one of the nodes includes means for 
regulating the use of said communicated digital information. 

487. A method for chain of handling and control 
characterized by the steps of (a) a first party placing protected 
digital information into a first software container and stipulating 



rules and controls governing use of at least a portion of said 
digital information, (b) providing said software container to a 
second party, wherein said second party places said software 
container into a further software container and stipulates rules 
and controls for at least in part managing use of at least a portion 
of said digital information and/or said first software container by 
a third party. 

488. A chain of handling and control system characterized 

by: 

means for placing digital information into a first software 
container and for stipulating rules and/or controls governing use 
of at least a portion of said digital information, and 

means for placing said software container into a further 
software container and for stipulating further rules and/or 
controls for at least in part managing use of at least a portion of 
said digital information and/or said first software container. 

489. A system for chain of handling and control including 
(a) a first container containing at least in part protected digital 
information, (b) at least in part protected control information 
stipulated by a first party establishing conditions for use of at 
least a portion of said digital content, (c) a second container 
different from said first container, said second container 
containing said first container, (d) control information stipulated 
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independently by a second party for at least in part setting 
conditions for managing use of the contents of said second 
container. 

490. A system for electronic advertising including: (a) 
means to provide digital information to users for their use, (b) 
means to provide advertising content to said users in 
combination with said digital information, (c) means to audit use 
of said digital information, (d) means to securely acquire usage 
information regarding use of advertising content, (e) means to 
securely report information based upon said advertising content 
usage information, (f) compensating at least one content provider 
at least in part based upon use of said advertising content. 

491. A method for electronic advertising characterized by 
the steps of (a) placing digital information into a container, (b) 
associating advertising information with at least a portion of said 
digital information, (c) securely providing said container to a 
container user, (d) monitoring user viewing of advertising 
information, and (d) receiving payment from an advertiser, 
wherein said payment is related to user viewing of said 
advertising information. 



492. A system for electronic advertising involving (a) 
means to containerize digital information including both content 



and advertising information, (b) means to monitor viewing of at 
least a portion of said advertising information, (c) means to 
charge for user viewing of at least a portion of said advertising 
information, (d) means to securely communicate information 
based upon said viewing in a secure container, and (e) control 
information related to said containerized digital information for 
managing the communication of said information based upon 
said viewing. 

493. A method for electronic advertising characterized by 
the steps of (a) containerizing digital information including both 
content and advertising information, (b) monitoring user viewing 
of at least a portion of said advertising information, (c) charging 
for user viewing of at least a portion of said advertising 
information, (d) securely communicating information based upon 
said viewing in a secure container, and (e) at least in part 
managing, through the use of control information related to said 
advertising information, the communication of information based 
upon said viewing. 

494. A method of clearing transaction information 
characterized by the steps of (a) securely distributing digital 
information to a first user of an interoperable protected 
processing environment, (b) securely distributing further digital 
information to a user of an interoperable protected processing 





environment different from said at first user (c) receiving 
information related to usage of said digital information, (d) 
receiving information related to usage of said further digital 
information, and (e) processing information received according to 
steps (c) and (d) to perform at least one of (I) an administrative, 
or (ID an analysis, function. 

495. A system for clearing transaction information 
including (a) a first container containing at least in part 
protected digital information and associated control information, 

(b) a second secure container containing further at least in part 
protected digital information and associated control information, 

(c) means to distribute said first and second containers to users, 

(d) communication means for communicating information at least 
in part derived from user usage of said first container digital 
information, (e) communication means for communicating 
information at least in part derived from user usage of said 
second container digital information, (f) processing means at a 
clearinghouse site for receiving the information communicated 
through steps (d) and (e), wherein said processing means perform 
administrative and/or analysis processing of at least a portion of 
said communicated information. 

496. A method for clearinghouse analysis characterized by 
the steps of: (a) enabling plural independent clearinghouses for 



administrating and/or analyzing usage of distributed, at least in 
part protected, digital information, (b) providing interoperable 
protected processing environments to plural, independent users, 
and (c) enabling a user to select a clearinghouse for use with an 
interoperable protected processing environment 

497. A system for clearinghouse analysis including (a) 
plural independent clearinghouses for administrating and/or 
analyzing usage of distributed, at least in part protected, digital 
information, (b) at least one interoperable protected processing 
environments at each of plural user locations, (c) selecting means 
for enabling a user to select one of said plural independent 
clearinghouse to perform payment and/or analysis functions 
related to the use of at least a portion of said at least in part 
protected, digital information. 

498. A method of electronic advertising characterized by 
the steps of 

creating one or more electronic advertisements, creating 
one or more secure containers including at least a portion of such 
advertisements, 

associating control information with such advertisements 
including control information describing at least one of: (a) 
reporting at least some advertisement usage information to one 
or more content providers, advertisers and/or agents, (b) 
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providing one or more credits to a user based on such user's 
viewing and/or other usage of such advertisements, (c ) reporting 
advertisement usage information to one or more market analysts, 
(d) providing a user with ordering information for and/or means 
for ordering one or more products and/or services, and/or (e) 
providing one or more credits to a content provider based on one 
or more users' viewing and/or other usage of such 
advertisements, 

providing such containers and such control information to 
one or more users, 

enabling such users to use such containers at least in part 
in accordance with such control information. 

499. A system for electronic advertising including (a) 
means to provide digital information to users for their use, (b) 
means to provide advertising content to said users in 
combination with said digital information, (c ) means to audit use 
of said digital information, (d) means to acquire usage 
information regarding use of advertising content, (e) means to 
securely report information based upon said advertising content 
usage information, and (f) compensating at least one content 
provider at least in part based upon use of such advertising 
content. 



500. A system for chain of handling and control including 
(a) a first container containing at least in part protected digital 
information, (b) at least in part protected control information 
stipulated by a first party establishing condition for use of at 
least a portion of said digital content, (c ) a second container 
different from said first container, said second container 
containing said first container, and (d) control information 
stipulated independently by a second party for at least in part 
setting conditions for managing use of the contents of said second 
container. 

501. A method of operating a clearinghouse characterized 
by the steps of receiving usage information related at least in 
part to use of secure containers from plural parties, determining 
payments due to one or more parties based at least in part on 
such usage information, performing and/or causing to be 
performed transactions resulting in payments to such parties 
based at least in part on such determinations. 

502. An electronic clearinghouse comprising: 

means for receiving usage information related at least in 
part to use of secure containers from plural parties, 

means for determining payments due to one or more 
parties based at least in part on such usage information, 



means for performing and/or causing to be performed 
transactions resulting in payments to such parties based at least 
in part on such determinations. 

503. A method of operating a clearinghouse characterized 
by the steps of receiving usage information related at least in 
part to use of secure containers from plural parties, determining 
reports of usage for one or more parties based at least in part on 
such usage information, creating and/or causing to be created 
reports of usage based at least in part on such determination, 
delivering at least one of such reports to at least one of such 
parties. 

504. A method of operating a clearinghouse characterized 
by the steps of receiving permissions and/or other control 
information from one or more content providers including 
information that enables delivery of at least one right in at least 
one secure container to other parties, receiving requests from 
plural parties for one or more rights in one or more secure 
containers, delivering permissions and/or other control 
information to such parties based at least in part on such 
requests. 

505. A method of operating a clearinghouse characterized 
by the steps of receiving information from one or more parties 



establishing a party's identity information, creating one or more 
electronic representations of at least a portion of such identity 
information for use in enabling and/or withholding at least one 
right in at least one secure container, performing an operation to 
certify such electronic representations, delivering such electronic 
representations to such parly. 

506. A method of operating a clearinghouse characterized 
by the steps of receiving a request for credit from a party for use 
with secure containers, determining an amount of credit based at 
least in part on such request, creating control information related 
to such an amount, delivering such control information to such 
user, receiving usage information related to use of such credit, 
performing and/or causing to be performed at least one 
transaction associated with collecting payment from such user. 

507. A method for contributing secure control information 
with respect to an electronic value chain wherein control 
information is contributed by a party not directly participating in 
said value chain, comprising steps of: aggregating said 
contributed control information with control information 
associated with digital information stipulated by one or more 
parties in an electronic value chain, said aggregate control 
information at least in part managing conditions related to the 
use of at least a portion of said digital information. 
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508. A method for entering the payment of taxes 
associated with commercial events wherein secure control 
information for automatically governing tax payments for said 
commercial events is contributed by a party comprising steps of: 
aggregating said secure control information with control 
information that has been contributed by a separate party and 
controlling at least one condition for use of digital information. 

509. A method for general purpose reusable electronic 
commerce arrangement characterized by the steps of: 

(a) providing component structures, modular methods that 
can be configured together to comprise event controlled 

(b) providing integrate able protected processing 
environments to plural independent users; 

(c) employing secure communications means for 
communicating digital control information between integrateable 
protected processing environments; and 

(d) enabling database managers operably connected to 
said processing environments for storing at least a portion of said 
provided component modular methods. 

510. A system for general purpose, reusable electronic 
commerce including: 

(a) component modular methods configured together to 
comprise event control structures; 



(b) at least one interoperable processing environment at 
each of plural independent user locations; 

(c) flPTVnr ^^""""^tinna Tnpana fnr mTnTnrmiontiTig 

digital control information between interoperable protected 
processing environments; and 

(d) secured database managers operably connected to said 
protected processing environments for storing at least a portion 
of said component modular methods. 

511. A general purpose electronic commerce credit system 
including: 

(a) a secure interoperable protected processing 
environment; 

(b) general purpose credit control information for 
providing credit for user usage of at least in part protected digital 
information; and 

(c) at least in part protected digital information related 
control information for providing necessary information for 
employing credit through the use, at least in part, of said general 
purpose credit control information. 

512. A method for enabling a general purpose electronic 
commerce credit system including: 

(a) providing secure interoperable protected processing 
environments; 



(b) supplying general purpose credit control information 
for providing credit for user usage of at least in part protected 
digital information; and 

(c) providing, at least in part, protected digital information 
related control information for providing necessary information 
for employing credit through the use, at least in part, of said 
general purpose credit control information. 

513. A document management system comprising one or 
more electronic appliances containing one or more SPUs and one 
or more secure databases operatively connected to at least one of 
the SPUs. 

514. An electronic contract system comprising one or more 
electronic appliances containing one or more SPUs and one or 
more secure databases operatively connected to at least one of 
the SPUs. 

515. An electronic appliance containing at least one SPU 
and at least one secure database operatively connected to at least 
one of the SPU(s). 

516. An electronic appliance containing one or more CPUs 
where at least one of the CPUs is integrated with at least one 
SPU. 



woy&u/ro 

517. An electronic appliance containing one or more video 
controllers where at least one of the video controllers is 
integrated with at least one SPU. 

518. An electronic appliance containing one or more 
network communications means where at least one of the 
network communications means is integrated with at least one 
SPU. 

519. An electronic appliance containing one or more 
modems where at least one of the modems is integrated with at 
least one SPU. 

520. An electronic appliance containing one or more CD- 
ROM devices where at least one of the CD-ROM devices is 
integrated with at least one SPU. 

521. An electronic appliance containing one or more set- 
top controllers where at least one of the set-top controllers is 
integrated with at least one SPU. 

522. An electronic appliance containing one or more game 
systems where at least one of the game systems is integrated 
with at least one SPU. 
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523. An integrated circuit supporting multiple encryption 
algorithms comprising at least one microprocessor, memory, 
input/output means, at least one circuit for encrypting and/or 
decrypting information and one or more software programs for 
use with at least one of the microprocessors to perform encryption 
and/or decryption functions. 

524. An integrated circuit comprising at least one 
microprocessor, memory, at least one real time clock, at least one 
random number generator, at least one circuit for encrypting 
and/or decrypting information and independently delivered 
and/or independently deliverable certified software. 

525. An integrated circuit comprising at least one 
microprocessor, memory, input/output means, a tamper resistant 
barrier and at least a portion of a Eights Operating System. 

526. An integrated circuit comprising at least one 
microprocessor, memory, input/output means, at least one real 
time clock, a tamper resistant barrier and means for recording 
interruption of power to at least one of the real time clocks. 
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